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(57) An apparatus and method is provided for transparent 
communication between a remote or mobile device (52) 
and a fixed communication host network (10). The 
apparatus and method may include a remote network 
controller (20) that logically resides between the host 
networic and the existing infrastructure(s) (56) that are 
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infrastructures existantes (56) utilisees pour etablir un 
contact de reseau de communication avec un ou plusieurs 
dispositifs (52) a distance. L'organe de commande de 
reseau a distance est connecte au reseau de 
communication bote comme un organe de conmiande de 
communication a protocole approprie de sorte que pour 
le reseau bote, les dispositifs a distance ne puissent etre 
distingues des dispositifs localetnent connectes (12). 
Chaque dispositif a distance peut comprendre une 
interface de donnees en serie asynchrone pour 
communiquer avec un organe de conmiande de donnees 
mobile (54). L'organe de commande de donnees mobile, 
en combinaison avec Torgane de commande de reseau a 
distance, effectue une communication de donnees de 
bout en bout de sorte que des protocoles incompatibles 
soient transparents pour le dispositif a distance et le 
reseau de conununication bote. Un routeur peut 
selectionner un reseau de communication conformement 
aux parametres configures des utilisateurs. La 
commutation entre plusieurs reseaux incompatibles est 
transparente pour le dispositif a distance el le reseau de 
communication bote. 



used to provide communications network contact with 
one or more remote devices (52). The remote network 
controller is connected to the host communication 
network as a protocol-appropriate communications 
controller so that remote devices are indistinguishable to 
the host network from the locally -attached devices (12). 
Each remote device may be provided with an 
asynchronous serial data interface to communicate with 
a mobile data controller (54). The mobile data controller, 
in combination with the remote network controller, 
provides end-to-end data communication such that 
incompatible protocols are transparent to the remote 
device and host communication network. A router may 
be provided which selects a commimications network in 
accordance with user configured parameters. Switching 
between the plurality of incompatible netwoiics is 
transparent to the remote device and host communication 
network. 
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(57) Abstract 

An apparatus and method is provided for trensparentcominuiuca- 
tion between a remote or mobile device (52) and a fixed oomihonication 
host network (lOX The apparatus and mettiod may include a remote net- 
woric controller (20) that logically resides between the host network and 
the existing infrastzuctuie(s) (56) tfiat are used to provide cominunica* 
tions network contact widi one or more remote devices (52). The remote 
network ccmtroller is connected to the hctst communication network as a 
protocol-appropriate conraumications controller so that remote devices 
are indistingid^iable to the host netwoiic finom the locallj^-attached de- 
vices (12). Each remote device may be provided with an asynchronous 
serial data interface to communtcate with a mobile data controller (54). 
Ihe mobile data controller, in combinaticm with the remote network con- 
troller, provides cnd-to-cnd data conununication such tltat incompatible 
protocols are transparent to die remote device and host communication 
network. A router may be provided which selects a communications 
network in accordance with user configured parameters. Switching be- 
tween the phnality of incompatible networks is transparent to die remote 
device and host communication networic 
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APPARAT US AND METHOD FOR INTELLIGENT ROUTING 
OF BATA BETWEEN A REMOTE DEVICE AND A HOST SYSTEM 

CONTINUTNG AND RELATED APPLICATION DATA 
TTiis is a continuation-in-part application of U.S. Patent Application No. 
08/456,860, filed on June 1, 1995, which is now U.S. Patent No. 5,717,737, issued on 
February 10, 1998, tlie content of vAdch is expressly incorporated herein by reference in 
its entirety. 

^, BACKG ROU N P O F TH E INVE N T ION 

The present invention relates to the transportation of data through dissimilar 
communications media. More particularly, the present invention relates to an apparatus 
and method for transporting data between a remote mobile or fixed terminal device and 
a host system over multiple, dissimilar communications media. The commimications 
media over which the data is transported include wireless data links, wired data links or 
a combination of wireless and wired data links which are selected based upon a set of 
preference metrics. 
2. Baskgromd MQimation 

The ability to transport data between mobile and/or fixed terminal devices and 
host computer systems have been generally available for many years. Networics designed 
to transport this data currently exist in a wide variety of wireless and wired network 
architectures. Both sipparatus and method exists for transporting data through multiple, 
similar media types :is well as the automatic selection of alternate communication paths 
based upon a plurality of preference metrics. 

Often, when multiple networks are available fit)m a common location such as a 
vehicle, great benefit may be derived by allowing imiform communications through all 
available networks. Certain networks may perform better for bulk data transfers where 
another may perform interactive messaging in an optimal fashion. One network may be 
preferable because of its low cost but an alternate, more expensive network may be 
acceptable as a backup if the low-cost nctworic is unavailable. 
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Other examples include U.S. Patent No. 5,412,375, to WOOD, which discloses 
a system for selecting one of a plurality of inter&ces to a single wireless communications 
system in accordance with the capabilities of a subscriber unit and the capabilities of a 
base unit. A list of air inter&ce capabilities of the subscriber unit and the base unit are 
compared by a controller to deteraiine a compatible interfece. As disclosed in WOOD, 
the plurality of air interfaces include Analog Mobile Phone System (AMPS), Time 
Division Multiple Access (TDMA) and Code Division Multiple Access (CDMA). While 
the WOOD system does select from one of a plurality of interfeces which may be 
applicable for data communication, the routing decision is based on the capabilities of 
the endpoints rather than the preference metrics of the transporting networks. The 
endpoint devices, in this case, must be aware of the peculiarities of the wireless 
environment 

U.S. Patent No, 5,420,574 , to ERICKSON et aL, discloses a subscriber unit 
attached to a trunked mobile radio having a data inpyXL The mobile radio communicates 
both voice and data message fomiats over a wireless network to a base station via 
charmels that are allocated by a trunked data controller which is connected to a host 
network. Channel states and communication parameters are set in accordance with the 
type of information {e.g., voice or data) that is being transmitted or received. While the 
ERICKSON et al. system dynamically switches between incompatible message formats 
without the intenrention of the endpoint devices, only a single data path is provided. In 
addition, the incorapatibiUty of the two alternate paths arises from a difference in 
message formats rather than the use of independent, incompatible networks. 

Further, the transportation of data through alternate, incompatible 
commimications media is a problem that does not have a uniform solution in the art. This 
problem is exacerbated in wireless communication networks where protocols, timing and 
other incompatibilities render an otherwise acceptable level of service inadequate. 
Attempts to provide data links through incompatible networks have suffered from the 
same obstacles that hindered data communications prior to open standards becoming 
widely accepted, i.e., proprietary protocols visible to the endpoint terminal devices make 
the devices inflexible and expensive and the intcropcration of similar devices with 
incompatible networking components is difficuh and complex. 
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Networizs may be interconnected by routers which operate at the network level 
and convey messages between compatible networks. Routers make logical decisions 
about the pathv^ay through which data is to be directed in the networks based upon a 
variety of preference metrics. A router is generally implemented as an autonomous 
device with multiple connections to the networics through which data is to be routed. 
Routers operate at the network layer and can recognize and manage protocols and 
multiple connections to networks. Routers usually operate in accordance with the 
address provided by the particular protocol of the network, and normally provide routing 
between and through networks utilizing the same network protocol and can route between 
networks that use different data-link layers, such as Ethernet, Token-Ring, Serial PPP, 
etc. Another type of router includes two routers loosely-coupled through a 
protocol-neutral data-link, where the linked routers are Considered as a single "virtual" 
router. 

Dissimilar networks may be connected by gateways which are devices that 
interconnect two or more dissimilar networks. A gateway differs torn a router in that the 
endpoint terminal devices may implement a dissimilar or incompatible protocols. 
Gateways often perform specific protocol conversions at the layers above the network 
layer to move data Jfrom one type of network to another. In this regard, the Open Systems 
Interconnection (OSI) model includes seven "layers" to provide conmiunications between 
heterogeneous (i.e., incompatible) systems. The layers, from lowest to highest, are: the 
physical layer, the data link layer, the network layer, the transport layer, the session layer, 
titt presentation layer, and the application layer. Each of the layers performs a specific 
task in transporting data between two or more entities. Such a layered structure is shown 
in The TCP/TP Comnanion. by Martin R. Arick, Wiley-QED, pp. 18-19. 

U.S. PiUent Application No. 08/456,860. to DOVIAK et al., for example, 
discloses a system in which a distant mobile or fixed terminal device transports data 
through a plurality of wireless network to an endpoint which may or may not implement 
the same network protocol as the distant device. However, while the DOVIAK. et al. 
system is capable transmitting data over a plurality of dissimilar wireless 
conununications networks, the S3^em does not automatically transmit data through 
differing ones of a plurality of dissimilar networics in accordance with preference metrics 
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to reach the data-link endpoints. Thus, the system does not automatically provide 
redundant or alternate pathways through which data may be delivered. 

U.S. Patent No. 5,537;220 to EZUMI et al., discloses a portable facsimile 
apparatus provided with a capability to communicate over a plurality of communications 
lines. As disclosed in E2XJMI et al., the facsimile machine may communicate over 
telephone lines or a mobile communication unit. A NCU (controller) is provided within 
the ^icsimile machine to discriminate whether the facsimile machine is connected to the 
telephone line or to the mobile communication unit The NCU functions to adjust the data 
rate, and transmitting and receiving signal levels based on which communication system 
it is communicating. Although this concept may be extended to a generic protocol-neutral 
data networking environment, the EZUMI et aL system provides for the selection of only 
one single path to the exclusion of other, possible viable path based solely on which link 
is plugged into the NOJ. Further, the EZUMI et al. system does not switch 
communication paths witiiin the boundaries of a communication session thereby fiirther 
limiting its useiiilness in a connectionless, packet data environment such as a TCP/IP 
network. 

U.S. Patent No. 5,602,843, to GRAY, discloses a PBX-based integrated 
teleconununications system having a wired subsystem connected to wired terminals, and 
a wireless system for connecting to mobile teiminals. A controller is provided which 
manages base stations and communicates to wireless handsets. When communicating 
to a handset, the controller determines which base station is in conmiunication with the 
handset and directs the base station to send packet-based information to that handset. A 
separate PBX controller is provided to commimicate with the wired terminals. The PBX 
controller includes a proximity sensor to detect wireless handsets such that when a 
handset is detected in proximity to a wired terminal, messages are forwarded to the wired 
terminal rather than the wireless handset. While the GRAY system dynamically selects 
the route to a terminal device based upon a preference metric (wireless proximity), the 
alternate routing technique does not address transporting data between the same two 
endpoints. In addition, GRAY provides no means to provide alternate path routing for a 
terminal device through either the wireless or wired handsets. 
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U.S. Patent No. 5.452,471, to LEOPOLD et al., discloses a communication 
system having a primary and one or more subordinate communication systems. In the 
illustrated embodiment, the primary communication system is a satellite-base 
communication system having the widest area of coverage. Each of the satellites within 
the system defines a cell area which moves as the orbiting satellites move. The 
secondary and tertiary communications systems are disclosed as terrestrial based, 
stationary systems having base stations fixed near the surface of the earth (e.g., fixed to 
a building), where each subordinate system has an increasingly smaller region of 
coverage. The secondary and tertiary systems include a controller located at a monitoring 
location within each region. Each of the communications systems includes a link to a 
central oflBce to enable communications over the public switched telephone network. The 
LEOPOLD et al. communication systems and mobile subscriber units operate within one 
frequency spectrum, however, the primary and secondary corrmiuiiication systems 
operate together by using orthogonal channels to prevent interference. In addition, when 
communicating with secondary systems, the mobile subscriber unit transmits at a 
relatively low power such that the primary system will not receive the transmissiort The 
mobile subscriber unit is progranmied to utilize the communication system having the 
smallest area of coverage such that if the subscriber unit has three coirmiunications 
systems available, the subscriber unit will utilize the tertiary communications system 
(i.e., the system having the smallest area of coverage) based on a designed assumption 
that the more subordinate the corrmiunication system is, the higher the capacity of the 
system. While the system of LEOPOLD et ai. dynamically selects a route based upon 
a set of preferaice metrics such that the terminal endpoints are unaware of the routing 
selection, a common data-link protocol is required throughout all possible associated 
networks. In Jiddition, the wireless frequencies employed must be derived from a 
continuous, compatible set of frequencies which prevents the device from selecting 
among inherently incompadble networks. 

Despite the teachings of these prior attempts, users of mobile or fixed wireless 
i\ ^ t f!\ communications are provided with systems of limited capacity and flexibility when 
routing data through more than one network. In addition, such systems require special 
hardware and/or software developed for and compatible with the networks, which may 
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require additiooal training of support personnel and end-users. Further, users of wireless 
mobile data communication services are provided with only a Umited ability to control 
costs associated with sending and receiving data to and from remote devices, and are 
limited in their hardware and software design implementations. In previous teachings, 
the-candidate networks must be compatible with one another at either the network or the 
data-link level. Thus, routing data through inherently incompatible networks such as 
Cellular Digital Packet Data (CDPD) and Ericsson ED ACS is not possible as these are 
incompatible at both the data-link and network levels. Moreover, known systems do not 
allow a customer to use existing RF wireless infirastructures, including existing hardware 
and software, wth only minor modifications needed to transport data from a mobile 
device to a host computer network. In addition, past attempts do not permit wireless data 
communications in a manner that is transparent to the remote device. Further, prior 
systems do not provide the flexibiUty to users such that a pluraUty of different remote 
devices may communicate with the wired host network irrespective of the radio 
infrastructure and transmission protocol employed. Such features, without the 
above-noted drawbacks, would be highly desirable to provide flexibiUty and ease of use, 
and to give u£:ers of portable data devices greater control over their hardware and 
software design. 

SUMMARY OF THE ]g-JVENTI QN 
In view of the foregoing, the present invention, through one or more of its various 
aspects, embodiments and/or specific features or sub-components thereof, is thus 
presented to bring about one or more objects and advantages, such as those specifically 
noted below. 

A general object of the present invention is to provide an apparatus and method 
for transporting data Scorn a remote, wireless device to a wired network. Another object 
of the invention is to provide a remote device with an interface to present data to the 
wired network through RF wireless communication. 

More particularly, an object of the present invention is to provide an apparatus 
that resides between an existing wired communications network and an existing 
radio-frequency network to provide a wireless RF cormection between a remote device 
and the wired network. 
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Another object of the present invention is to provide an apparatus and method for 
a completely tnmsparent data path between a remotely located device and an existing 
wired nctwoA xising a wireless RF communications link without cither the remote 
device, or the v/ircd network being aware that a wireless RF communications link is 
being employed. 

Still another object of the present invention is to provide an apparatus and method 
for a completely' transparent data path between a remotely located device and an existing 
wired network dirough a plurality of different wireless RF coramimications link protocols 
and a plurality of different wired networks protocols selected by the user. 

Still another object of the present invention is to provide an apparatus which 
fimctions as a protocol-appropriate communications controller and makes remote devices 
indistinguishable from locally attached devices to a wired network. 

According to one aspect of die present invendon, an apparatus for transporting 
data between a remote device and a host communication network using a wireless 
communications link is provided. The apparatus comprises a mobile data controller 
connected to the remote device and the wireless communicatioiis link. The mobile data 
controller comprises a remote data conversion means for converting data to be 
transported betv/een the remote device and the host communication network. The remote 
data conversion means converts the transported data between a remote device 
transmission format utilized by the remote device and a wireless link transmission format 
utilized by the wireless communications link. 

' The apparatus also comprises a network interface means for interfacing the host 
communication network with the wireless communications link. The network interface 
means comprises a wireless link conversion means for converting the transported data 
between the wii^eless link transmission format and a network interfece format utilized by 
the network interfece means; and a host network conversion means for converting the 
transported datJi between the network interface format and a host network format utilized 
by the host communication network. 

The apparatus further comprises a means for transporting the transported data 
over the wireless conununication in accordance with the wireless link transmission 
format, the wireless link transmission format and the host network format being 
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incompatiblc. /according to another aspect of the present invention, the network interface 
means comprises a remote network controller that logically resides on the host 
communication network and pcrfonns the functions of a network communication 
controller 

According to another aspect of the present invention, the apparatus for 
transporting data further comprises a plurality of networic interface means coimected by 
a local network and a synchronization means for synchronizing the transfer of 
information between the netwo± interfece means, the information comprising routing 
tables and healtji and status information. 

According to the present invention a method of transporting data from a mobile 
device to a host network is provided. The remote device and a wireless communications 
link are connected by a mobile data controller, and the host conmiunication network and 
the wireless communications link being interfaced by a network interface device. 

The method includes the steps of: converting, at the mobile data controller, data 
to be transported between tihe remote device and the host communication network, the 
converting step converting the transported data between a remote device transmission 
format utilized by the remote device and a wireless link traiismission format utilized by 
the wireless communications link; transporting the transported data over the wireless 
coirmaunicatioES link in accordance with the wireless link transmission format; receiving, 
at the network mtcriaco device, the transport data from the wireless communications link; 
converting, at tlie network inter&ce device, the transported data between the wireless Unk 
transmission format and a network interface format utilized by the network interface 
device, the wireless link transmission format and the host network format being 
incompatible; fiirther converting, at the network interface device, the transported data 
between the network interface format and a host network format utilized by the host 
communication network; and forwarding the transported data to the host communication 
network in accordance with the host network format. 

In a preferred embodiment, the transportation step fiirther comprises determining 
wireless communications link selection criteria; dynamically selecting a wireless 
communications link from a plurality of incompatible wireless conununications links in 
accordance with the selection criteria; and switching to the selected wireless 



CA 02303987 2000-03-16 



P1705LS01 -9- 

communicatioas link. Afterwards, the following steps are continuously repeated: 
dynamically selecting a next wireless communications link from the plurality of 
incompatible networks in accordance with the selection criteria; detcnnining whether to 
switch wireless conamunications links; and switching to the next wireless 
conimunications link in response to a result of the determinatioa 

According to another aspect of the present invention, an apparatus for transporting 
data over a plurality of incompatible networks between a first device and a second device 
is provided. The apparatus comprises a system for determining network selection 
criteria. In addition, the apparatus comprises a selection system for dynamically selecting 
a network from the plurality of incompatible networks in accordance with the network 
selection criteria and a switching system for switching to the selected network to use for 
data transport. 

According to another aspect of the present invention, the apparatus transports data 
via a plurality of protocols over a plurality of incompatible networks in which the 
transportation of data is transparent to the first and second devices and to an end user. 
The protocols may include but are not limited to Internet Protocol (IP) and transparent 
protocol. 

According to another aspect of the present invention, the apparatus for 
transporting data further comprises a system interfecing protocolized data into a plurality 
of incon^)atible networics using different protocols. 

According to another aspect of the present invention, the switching system 
switches networks during the time between the transport of consecutive data packets. 

According to another aspect of the present invention, the system for determining 
network selection criteria uses two classes of parameters to determine the next netwoik 
to use for txansj)ort of data. 

According to another aspect of the present invention, the selection system fiirther 
determines a next network to switch to from the plurality of incompatible networks in 
accordance with the networic selection criteria, when the selected network becomes 
unavailable. In addition, a monitoring system is provided which monitors the availability 
of the incompatible networks to determine whether the next network is available for data 
transport. 
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The above-listed and other objects, features and advantages of the present 
invention will be more fiiUy set forth hereinafter. 

BRIEF DESCRIPTION OF THE DRAWINGS 
The present invention is further described in the detailed description which 
follows, by reference to the noted plurality of drawings by way of non-limiting examples 
of preferred embodiments of the present invention, in which hke reference numerals 
represent similar parts throughout the several views of the drawings, and wherein: 

Fig. I illustrates a general overview of a remote network controller and mobile 
data controller in accordance with an aspect of tlje present invention; 

Fig, 2 illustrates a block diagram of the basic components of the remote network 
controller and mobile data controller of the present invention; 

Fig. 3 is a high-level flow chart, according to ^he present invention, of the 
outbound data from a wired communicatioa network to a remote device; 

Fig. 4 is a high-level flow chart, according to the present invention, illustrating 
the flow of inbc»und data from a remote device to a wired communication network; 

Fig. 5 illustrates a block diagram of the components of a mobile interface in 
accordance with the present invention; 

Fig. 6 is a flow chart of the processing of an event handler and multithreading 
dispatcher associated with the mobile interface of the present invention; 

Fig. 7 is a flow chart for indicating the process flow of a process initialization 
module associated with the mobile interface of tiie present invention; 

? Fig. 8 is a flow chart for indicating the processing of a mobile session manager 
associated with the mobile interface of the present invention; 

Fig. 9 is a flow chart of the processing steps for an inbound data event handler 
associated with the mobile interface of the present invention; 

Fig. 10 is a flow chart of the processing steps for an outbound data event handler 
associated with the mobile interface of the present invention; 

Fig. 1 1 is a flow chart of the processing steps for a process termination module 
associated with the mobile interface of the present invention; 

Fig. 12 is a flow chart of the processes associated with a host data controller 
interface module associated with the mobile interface of the present invention; 
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Fig. 13 is a block diagram of the various components of a host data controller in 
accordance with an aspect of the present invention; 

Fig. 14 is a block diagram of the components comprising a service interface 
according to the present invention; 

Fig, 15 is a flow chart of the processing of an event handler and multithreading 
dispatcher associated with the service interface of the invention; 

Fig. 16 is a flow chart describing the process flow of a process initialization 
module associated with the service interface of the invention; 

Fig. 17 is a flow chart of the processing steps for an inbound data event handler 
associated with the service inter&ce of the present invention; 

Fig. 18 is a flow chart of the processing steps for an outbound data event handler 
associated with the service interface of the present invention; 

Fig. 19 is a flow chart of the processing steps for a process termination module 
associated with the service interface of the present invention; 

Figs. 20, 21, 22, 23 A, 23B and 24 are flow charts of the various processes 
associated with a wired communication network interface module associated with the 
service interface in accordance with the present invention; 

Fig. 25 is a block diagram of the various components of a mobile data controller 
of the present invention; 

Fig. 26 is a block diagram of the various components of a remote gateway 
according to another aspect of the present invention; 

Figs. 27 and 28 illustrate a block diagram of a remote network controller in 
accordance with still another aspect of the present invention, in which a subsystem 
synchronization process module is utilized; 

Fig. 29 illustrates a general overview of another embodiment of the present 
invention which includes a mobile router in accordance with an aspect of the present 
invention; 

Fig. 30 illustrates a schematic block diagram of the mobile router in accordance 
with an aspect of the present invention; 

Fig. 3 1 is an illustration of a block diagram of the functional components of the 
router in accordance with an aspect of the present invention; 
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Fig. 32 is an illustration of a block diagram of the switch within the router 
according to the present invention; 

Fig. 33 is an illustration of a flow chart of the processing steps used by the router 
to initialize and build tables stored in the Router in accordance with an aspect of the 
present invention; 

Fig. 34 is a flow chart of the processing steps used by the router for checking 
availability of each network interface in accordance with an aspect of the present 
invention; 

Fig. 35 is a flow chart of the processing steps used by the router to account the 
availability of tlie channels and the user's configuration in order to decide which channel 
to use for transi)orting data in accordance with an aspect of the present invention; 

Fig. 36 is a flow chart of the processing steps used by the router for an error 
handler in accordance with an aspect of the present invention; and 

Fig. 37 is an illustration of the software architecture of the Router in accordance 
with an embodimeiit of the present invention. 

DFTAn.HD DESCRTPTTON OF THE ILLUSTRATED EMBODIMENTS 
Referring now to the accompanying drawings. Fig. 1 illustrates a general 
overview of a remote network controller and a mobile data controller in accordance with 
an aspect of the present invention. In Fig. 1, a wired communication netwo± 10 is 
shown as a host network system having communications controllers 15 and 
locally-attached devices 12. The wired communication network 10 may be, for example, 
a Token Ring network or an Ethernet Local Area Network (LAN). The locally-attached 
devices 12 may mclude a personal computer, a workstation, a printer or network server, 
and reside at a pliu^ity of dispersed locations. According to the present invention, a 
remote network controller 20 may also be provided which logically resides on the wired 
communication network 10 and acts as a protocol-appropriate communications controller 
to send and receive data to and from the communications network 10 and one or more 
remote or mobile devices 52. For purposes of illustration, only one of the remote devices 
52 is shown in Fig. I. 

Remote devices 52 corrununicatc via a mobile data controller 54 and a wireless 
radio-frequency (RF) commuiucations link 55 created by the user's radio infrastructure 
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56 to the remote network controller 20. The mobile data controller 54 may convert 
asynchronous data from the remote device 52 into an appropriate protocol fonnat of the 
radio infiastructure 56. In accordance with an aspect of the present invention, the remote 
devices 52, although not physically connected to the wired communication network 10, 
are logically coimected to the wired communication network 10 through the radio 
infiastructure 56 and the remote networic controller 20 and are indistinguishable fixjm 
locally-attached devices 12. The remote devices 52 may be, for example, a laptop 
computer, personal digital assistant (PDA), a credit card reader, or a global positioning 
system (GPS) receiver. The radio infiastructure 56 may comprise a conventional point 
to point or trunking radio system. 

The logical connection created by the remote network controller 20 between the 
remote device 52 and the wired communication network iO is "transparent" to the user 
of the remote device 52, and to the wired communication network 10. In accordance with 
an aspect of the invention, the remote network controller 20 takes data transported by the 
radio infiastructure 56, irrespective of die format protocol of the radio infrastructure, and 
converts the data into a format protocol recognized by the wired network 10. Similarly, 
the remote netv/ork controller 20 of the present invention takes data from the wired 
network 10 and converts the data into a format protocol recogrdzed by the radio 
infrastructure 56. Accordingly, the user of the remote device 52 does not have to 
perform any additional steps to send and receive data to and from the vmed 
communication network 10, and the wired conmiunication network 10 does not have to 
perform any additional steps to send and receive data to and from the remote device 52. 
The user of the remote device 52 interacts with the wired communication netwoiic 10 in 
a similar manner as a user of the locally-attached devices 12. Similarly, the wired 
communication network 10 interacts witii the remote device 52 in a similar manner as the 
wired communication network interacts with the locally-attached devices 12. 

Referring now to Fig. 2, there is illustrated a block diagram of the basic 
components of the remote networic controller 20 of the present invention. Each 
component of the remote network controller 20 will be generally described for 
introductory purposes and will later be described in greater detail below with reference 
to the accompajiying drawings. The various components of the host data controller 22 
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and the mobile data controller 54 will also be discussed hereinafter with reference to Figs. 
13 and 25, respectively. 

As shown in Fig. 2, the remote network controller 20 may comprise a service 
interface 30, a mobile inter&ce 24, an interprocess communication manager 28, a control 
process module 26, and a console interface 34. The remote network controller 20 may 
be implemented through a collection of software program modules and hardware 
components working cooperatively. The remote network controller 20 itself may run on 
a standard platform, such as a personal computer (PC) equipped with a commercially 
available processor or multi-processor, e.g., an Intel or Motorola based processor or 
multi-processor, and a conmiercially available operating system, such as an MS-DOS or 
UNIX based operating system. The remote network controller 20 may also contain an 
Ethernet controller or suitable network controller card depending on the wired 
communication network 10. In addition, the remote network controller 20 may include 
random access memory and physical storage media including hard disk and tape storage 
devices. 

The wired communications network 10 is coimected to the remote network 
controller 20 by the service interface 30. The service interface 30 handles all network 
coimections. If several wired communications networks 10 are present, one or more 
service interfaces 30 may be provided to handle wired network connectivity. The service 
interface 30 connects to an interprocess communication manager 26. The interprocess 
communication manager 28 manages all inter-process message routing within the remote 
n^ork controllo: 20. One or more mobile inter&ces 24 may also be provided to handle 
coimectivity with the radio infrastructure(s) 56. Each mobile interface 24 is also 
connected to the interprocess conununication manager 28. The control process module 
26 of the remote network controller 20 is provided to process management functions and 
data integrity. The control process module 26 is connected to the interprocess 
communication manager 28 and the console interface 34. The console interface 34 
allows for user configuration and reporting of data. 

As further illustrated in Fig. 2, the remote network controller 20 may be 
connected to a host data controller 22. One or more host data controllers 22 may be 
provided for connecting the remote network controller 20 to specific radio infrastructures 
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56, e.g., a Motorola tmnked radio. The host data controller 22 may be connected to the 
mobile interface 24 of the remote network controller 20. 

In the field, the remote device 52 is connected to the mobile data controller 54 
which, in tum, is connected to the radio infirastructurc 56 for transmitting and receiving 
data: The mobile data controller 54 is responsible for connecting the remote device 52 
to the radio infrastructure 56 and to provide protocol-independent asynchronous serial 
data transfer to iind from the remote device 52. 

In order to provide transparent data transportation, whereby the network protocols 
and the protocols of the radio infrastructure 56 arc transparent or invisible to the user, 
inboimd asynchronous data from the remote device 52 is collected and transported to the 
wired communication network 10 in packets over the radio infrastructure 56. The data 
is sent using the existing protocols of the radio infrastructure 56. The remote network 
controller 20 accepts the data and encapsulates it into the appropriate protocol used by 
the wired communication network 10. The data is passed to the wired communication 
network 10 in a similar fashion for passing data from any of the other locally-attached 
devices 12. Similarly, outbound data to the remote device 52 from the wired 
communication network 1 0 is removed from the network protocol by the remote network 
controller 20. The remote network controller 20 then encapsulates the data into the 
appropriate protocol associated with the radio infrastmcture 56 and sends the data over 
the radio infrastructure 56 to the mobile data controller 54. Upon receipt of the data, the 
mobile data controller 54 removes the data from the radio infrastructure protocol and 
asynchronously sends the data to the remote device 52. 

In accoi-dance with the present invention, multiple wired networks 10 with 
different protocols may be linked to multiple RF environments in any combination by 
incorporating tlie remote network controller and mobile data controller of the present 
invention. 

Fig. 3 is a high-level flow chart for transporting outboimd data from the wired 
communication networic 10 to the remote device 52. As shown in Fig. 3, when data is 
to be sent to tlie remote device 52, the service interface 30 of the remote network 
controller 20 accepts data from the wired communication network 10 at step 500. The 
service interface 30 then converts the data from the protocol used by the wired 
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communication network 10 and encapsulates it into an internal protocol used by the 
remote network controller 20 at step 502. In addition, the service interface 30 may 
receive routing infonnation from the wired communication network 10 as to what remote 
device 52 the data is to be passed, e.g., a network address or device identifier of the 
remote device 52. 

At step 504, the service interface 30 forwards the data to the interprocess 
communication manager 28. The interprocess communication manager 28 accepts the 
data at step 506 and^ at step 508, places the data in a queue for the appropriate destination 
mobile interface 24. The destination mobile interface 24 may depend on the radio 
infrastructure 56* employed by the user. The outbound data that is to be passed from the 
interprocess communications manager 28 to the mobile interface 24 may be encapsulated 
in an internal protocol of the remote network contrgller 20, along with routing 
information to specify the remote device 52 to which the data is to be sent. At step 5 10, 
the interprocess communication manager 28 notifies the mobile interface 24 that the data 
to be sent to the remote device 52 is queued for the mobile interface. The particular 
mobile interface 24 that the data is queued for depends on the particular radio 
infirastructure 56 employed to communicate with the destination remote device 52. At 
step 512, the mobile interface 24 requests that the queued data be sent from the 
interprocess cormnunication manager 28. The mobile interface 24 may request data when 
. it is free to send the data to a destination remote device 52 and not handling another 
process. At step 514, the mobile interface 24 accepts the queued data frt>iri the 
interprocess commtinication mans^er 28. Thereafter, at step 516, the mobile interface 
24 determines, based on the queued data, the destination node address of the remote 
device 52 to which the data is to be sent. At step 518, the niobile interface 24 forwards 
the data to the appropriate host data controller 22 so that it may be sent over the radio 
infirastructure 56 at step 520. According to an aspect of the present invention, the host 
data controller 22 may receive the data, remove it from the internal protocol and 
encapsulate the data into a packet determined by the protocol used by the radio 
infrastructure 56. The packet of data may be broadcasted over the radio infinsmicnire 56 
so as to enable the host data controller 22 to communicate with multiple mobile data 
controllers 54 simultaneously. The broadcasted data packet may include the 
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identificadon of the specific mobile data controller 54 to which the packet is to be 
dehvered, so thiit only uniquely identified mobile controller's) may accept the packet. 

Referring again to Fig. 3, at step 522, the mobile data controller 54 receives the 
5 data &om the remote radio infi^tnicture 56 and decodes the data. The data packet, once 

received by the mobile data controller 54. is accepted and the data is removed from the 
packet. At step 524, the mobile data controller 54 validates the data and, at step 526. 
sends an acknowledgment or rejection message to the host data controller 22 via the radio 
infrastructure 56. According to the present invention, the remote network controller 20 
10 and tiie host daul controller 22 may be responsible for ensuring the integrity of the data 

transported over the radio infrastructure. As such, an error detection/retry mechanism 
may be employed to detect and correct data transmission errors. After the integrity of the 
data is verified, the mobile data controller 54 at step 528 will forward the data to the 
remote device 52. The data may be asynchronously transferred to the remote device 52 
15 through a serial connection. 

Fig. 4 is a high-level flow chart illustrating the processing of inbound data firom 
the remote device 52 to the wired communication network 10. At step 550, the mobile 
data controUer 54 accepts data from the remote device 52. At step 552, the mobile data 
controller 54 formats and sends the data to the remote network controller 20 via the radio 
20 infrastructure 56, which may comprise a modem. The data may be transmitted using the 

appropriate protocol of the radio infrastructure 56. The data may be modulated within 
the mobile data controller 54 prior to transmission via the radio mfi^structure 56. The 
mobile data controUer 52 may place the data from the remote device 52 into packets to 
be sent over the radio infrastructure 56. The packet size can be determined by one of 
25 three methods. The first is a maximum packet size. Once an upper limit of data is 

accumulated, the mobile data controller 54 may send the packet of information to the host 
data controller 22. For example, once 256 bytes of data arc coUected, the data may be 
sent by the radio infrastructure 56 over the RF communications Unk 55. The second 
method is a m;iximum time to wait before sending data. In this case the mobile data 
30 controller 54 will send a packet after waiting a predetermined period of time, no matter 

how much data is accumulated. The third method involves the mobile data controller 54 
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detecting a predefined "end-of-packet" character which causes all accumulated data to 
be transmitted. 

At step 554, the host data controller 22 receives and decodes the data packet ftom 
the protocol of the radio infrastructure 56. Generally, the data arrives as a packet of a 
predetermined size. At step 556, the host data controller 22 validates the data and, 
thereafter, sends at step 558 an acknowledgment or rejection message to the mobile data 
controller 54 based on the validation process. According to an aspect of the present 
invention, the host data controller 22 may determine if the transmitted data packet is 
correct, or in error. The host data controller 22 may also determine if the data packet has 
arrived in the proper sequence, and that the packet is not a duplicate. As discussed above, 
the inbound data may be removed from the packet and encapsulated in the internal 
protocol used by the remote network controller 20. The internal protocol may contain 
additional information^ such as the identification of the mobile data controller 54 which 
sent the inform;mon. 

At step .560, the host data controller 22 forwards the data to the mobile interface 
24. The mobile interface 24 accepts the data from the host data controller 22 at step 562. 
The mobile interface 24 validates the address of the source of the data (e.g., the particular 
mobile data controller 54 or remote device 52) at step 562. At step 566, the mobile 
interface 24 fomards the data to the interprocess communication manager 28, which 
accepts the data at step 568. The mobile interfece may also pass the routing information 
specifying the remote device 52 from which the data originated. At step 570, the 
interprocess communication manager 28 places the data into a queue for the destination 
service interfece 30. The particular destination service interface 30 will depend upon 
which wired communication network 10 the data is to be delivered. Included in the 
information which is passed to the service interface 30 is the destination address (i.e., the 
communication network 10 to which the data is to be delivered). At step 572, the service 
interface 30, when available to handle data, requests the data from the interprocess 
communication manager 28. The service interface 30 accepts the data at step 576 and 
converts the data into an appropriate form, i.e., protocol, usable by the wired 
conununication network 10 at step 578. As a result, the data may be passed to the 
hardware device (e.g., an Ethernet controller) using the protocol required by the wired 
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communication network 10. This configuration allows any existing network interface 
card to be used in conjunction with the remote network controller 20, because the data 
is placed into the appropriate networic protocol by the service interface 30 before it is 
transmitted to the wired network. At step 580, the service interface 30 forwards the data • 
to the wired communication networic 10. 

The validation process of the outbound data depicted in Fig. 3 and inbound data 
depicted in Fig. 4 does not depend on the type of wired commxmication network 10 
employed by the user. Through a single validation process performed by the host data 
controller 22 and the mobile data controller 54 (see steps 524 and 526 in Fig. 3 and steps 
556 and 558 in Fig, 4), the integrity of the data transmitted from the wired 
communication network 10 to the remote device 52 through the radio infrastructure 56 
is ensured. This validation process may include, for example, an error detection and retry 
mechanism to detect errors and to cause (when necessary) the retransmission of the data. 

Referring now to Fig. 5, there is illustrated a block diagram of the basic 
components of the mobile interfece 24 of the remote network controller 20 of the present 
invention. As noted above, the mobile interface 24 is responsible for interfacing the 
remote networi: controller 20 with the host data controller 22 and the radio infrastructure 
56. The mobile interface 24 may be a software interface that records statistical 
information related to inbound and outbound data. The mobile interface 24 may also be 
responsible for enor detection and cocrection, and establishing and managing the mobile 
data sessions wife the remote devices 52. The number of mobile interfaces 24 provided 
iibthe remote network controller 20 depends on the number of different types of radio 
infrastructures 56 employed by the user. Each type of radio infrastructure 56 may have 
its own associated mobile interfece 24. 

As shown in Fig. 5, the mobile interface 24 may include an event handler and 
multithreading dispatcher 60, a process initialization module 62, a mobile session 
manager 64. an inbound data event handler 66, an outbound data event handler 68, a 
process termination module 70 and a host data controller interfece module 72. The event 
handler and multithreading dispatcher 60 may contain high-level logic and be used to 
control the overall execution flow of the mobile interface 24. The process initialization 
module 62 may be utilized to acquire resources and establish the operation environment 
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for the mobile interfece 24 process. The process initialization module 62 may also be 
provided to initialize the host data controller 22. 

AccordiBg to the present invention, the mobile session manager 64 may be 
provided to conlxol the communications environment between the mobile data controller 
54 and the host data controller 22. The inbound data event handler 66 responds to signals 
from the host data controller 22 indicating that inbound data is available and preprocess 
session control information. The outbound data event handler 68 is provided to respond 
to signals fixam the interprocess communication manager 28 indicating that outbound data 
is available or that a session control function is required. The process termination 
module 70 functions to release previously-acquired resources and terminate the mobile 
interface 24 process efficiently. The host data controller interface module 72 handles 
low-level interaction with the associated host data cohtrqller(s) 22. 

The process flow of the event handler and multithreading dispatcher 60 will now 
be described with reference to Fig. 6. At step 600, the process begins when the remote 
network controller 20 is powered up and initialized. At step 602, the process 
initialization module 62 is invoked (described below with reference to Fig. 7). At step 
604, the event handler and multithreading dispatcher 60 waits for an event (e.g., receipt 
of inbound data) to occur. While the event handler and multithreading dispatcher 60 
waits for an event to occur, mobile interface 24 may be placed in a "sleep" mode to 
conserve processor resources. At step 606, once an event occurs, the event handler and 
multithreading 'dispatcher 60 determines if it is a recognized event. If the event handler 
and multithreading dispatcher 60 determines it is not a recognized event at step 606, 
processing returns to step 604. If, however, the event handler and multithreading 
dispatcher 60 determines that the event is a recognized event at step 606, then processing 
continues at step 608, where the event handler and multithreading dispatcher 60 
determines if tlie data was received fix)m the host data controller 22. 

At step 608, if the event handler and multithreading dispatcher 60 determines the 
data was received from the host data controller 22, the event handler and multithreading 
dispatcher 60 invokes the inbound data event handler 66, at step 614 (described below 
with reference to Fig. 9) and processing continues at step 604. If at step 608 the event 
handler and multithreading dispatcher 60 detemaines that the data was not received bom 
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thc host data controller 22, then the event handler and multithreading dispatcher 60 
detennines whether the data was received from the service interface 30 at step 610. 

If the event handler and multithreading dispatcher 60 at step 610 determines that 
the <iata was received from the service interface 30, then at step 616 the outbound data 
event handler 63 is invoked (described below with reference to Fig. 10) and processing 
returns to step 604. If the event handler and multithreading dispatcher 60 at step 610 
determines tiiat the data was not received from the service interface 30, then at step 612 
the event handler and multithreading dispatcher 60 determines if there is a process 
termination request 

If, at step 612, the event handler and multithreading dispatcher 60 determines 
there is a process teraiination request, then at step 61 8, the process termination module 
70 is invoked (described below with reference to Fig. Jl). If, at step 612, the event 
handler and multithreading dispatcher 60 determines that there is not process termination 
request, then processing continues at step 604 to wait for another event 

Referring now to Fig. 7, there is illustrated an exemplary flow chart for indicating 
the process flow of the process initialization module 62 of Fig. 5. At step 620, the 
interprocess communications interface is setup. At step 622, the operating environment 
parameters are parsed and processed. This includes the host data controller 22 parameters 
referenced in steps 626, 632 and 634 below. At step 624, memory is allocated for the 
session and otlier tables contained within the mobile interface 24, which are used to 
control data flow and other operations. At step 626. the host data controller 22 
parameters are accessed. At step 628, a path to the host data controller 22 port is opened. 
At step 630, the host data controller 22 then is prevented from monitoring for an event 
from the remote device(s) 52. Step 630 prevents erroneous transmissions that may arise 
if the host data controller 22 attempts to monitor a remote device 52 before the 
initialization process is complete. At step 632, the host data controller 22 communication 
parameters are set. At step 634, the communication parameters are downloaded to the 
host data controller 22. After the initialization processes of steps 632 and 634 are 
completed, the host data controller 22 at step 636 is enabled to monitor the remote 
dcvice(s) 52. At step 638, the entire initialization procedure is complete and processing 
returns to step 604 in Fig. 6. 
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Referring now to Fig. 8, there is illustrated an exemplary flow chart describing 
the logic flow of the mobile session manager 64 of Fig. 5. At step 640, the mobile 
session managtrr 64 handler is entered from the event handler and multithreading 
dispatcher 24 v/hen remote data is detected At step 642, the remote identifier of the 
remote device 52 is looked up in a session table. At step 644, the mobile session 
manager 64 determines if the remote identifier was found in the session table. If the 
mobile session manager 64 detemiines that the remote identifier was foimd, the address 
is returned from the session table at step 646, 

If the mobile session manager 64 does not find the remote identifier at step 644, 
then at step 648* the mobile session manager 64 attempts to authenticate the remote 
identifier. At step 650, the mobile session manager determines if the authentication is 
succcssfiil. If ai: step 650 the authentication is successful, then at step 656 the host data 
controller 22 is instructed to connect to the remote device 52 based on the remote 
identifier. After the host data controller 22 is connected to the remote device 52, the 
appropriate service interface 30 is invoked at step 658. At step 660, processing is 
complete. If at step 650, the authentication was not successful, the remote data is ignored 
at step 652, and a null session table entry address is returned by the mobile session 
manager 64. 

Referring now to Fig. 9, there is illustrated an exemplary flow chart of the 
processing steps of the inbound data event handler 66 of Fig. 5. At step 662, the inbound 
data event handler is invoked (from step 614 in Fig. 6). At step 664, the remote identifier 
of the remote device 52 is checked against the session table. At step 666, it is determined 
whether the inbound data event handler 66 found the remote identifier in the session 
table. If at step 666, the remote identifier is not found in the session table, the data is 
ignored and processing continues at step 604 in Fig. 6. If the remote identifier is found 
in the session table at step 666, the data is sent to the service interface 30 at step 670. 
Processing then continues at step 604 in Fig. 6. 

Referring now to Fig. 10, there is illustrated an exemplary flow chart of the 
processing stq)s of the outbound data event handler 68 of Fig. 5. At step 672, the 
outbound data event handler is invoked (from step 616, Fig. 6). At step 674, the session 
table is checked for the outbound data remote identifier. At step 676, it is determined if 



CA 02303987 2000-03-16 



P 17051. SOI -23- 

the outbound data event handler 68 found the remote identifier in the session table. If at 
step 676, the remote identifier is not found in the session table, an error is logged and the 
data message is ignored. Processing then continues at step 604 in Fig. 6. If the remote 
identifier is found in the session table at step 676, the data is sent to the remote device 52 
as a single packet at step 680. Processing then continues at step 604 in Fig. 6. 

Referring now to Fig. 11, there is illustrated an exemplary flow chart of the 
processing steps of the process temaination module 70 of Fig. 5. At step 682, the process 
tennination module 70 is invoked (from step 618 in Fig. 6). At step 684, the process 
teraiination module 70 detennines if there are any active remote sessions. If, at step 684, 
it is detennined by the process tennination module 70 that there are no active sessions, 
then at step 686 all files are closed and the mobile interface 24 terminates. If, however, 
it is detennined by the process tennination module 70 that there are active sessions, then 
at step 688 all of the active sessions are issued a disconnect request. At step 690, the 
process termination module waits for all active sessions to terminate. Once all active 
sessions have terminated at step 690, then all files are closed and the mobile interface 24 
terminates at step 686. 

Referring now to Fig. 12, there is illustrated an exemplary flow chart of the 
processes associated with the host data controller interface module 72 of Fig. 5. The host 
data controller interface module 72 consists of a number of discrete fimctions (e.g.. 
Initialize, Command, Send Data, and Receive Data) which are called when needed by the 
mobile interface 24 and share common information about the host data controller 22. 
The host data controller interface module 72 may access the host data controller 22 via 
a serial communications port which is assigned to the mobile interface 24 and remains 
fixed when the remote network controller 20 is in operation. 

A host data controller 22 initialize routine begins at step 692. The initiaUzation 
routine may be initiated in accordance with step 602 (see Fig. 6) and steps 632 and 634 
(see Fig. 7). At step 694, the serial communications port is accessed and setup. 
Thereafter, at step 696. the port handle and status is saved to be used by other processes 
within the host data controller interface module 72. 

A host data controller 22 command routine begins at step 698. The command 
routine may be initiated upon the occurrence of a recognized event (see, e.g., step 604 in 
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Fig. 6) so that the appropriate control or operation commands may be sent to the host data 
controller 22. At step 700, the host data controller 22 is placed into a command mode. 
At step 702, a command (e.g., disconnect or receive) is issued to the host data controller 
22 based on the event that is recognized. At step 704, the host data controller interface 
module 72 awaits a confirmation of acceptance of the command from the host data 
controller 22. At step 706, the result of the command is returned to the host data 
controller interface module 72. 

A host data controller 22 send data routine begins at step 708 and may be initiated 
from step 680 in Fig. 10. The send data routine is initialized so that data may be sent to 
the appropriate remote device 52. First, the physical identification of the remote device 
52 is determined at step 710. Thereafter, the data to be sent to the remote device 52 is 
placed into a packet at step 712, and sent to the host datah-controUer 22 at step 714. 

At step 716, a host data controller 22 receive data routine is initiated in 
accordance with step 670 in Fig. 9. The receive data routine is initiated so that data from 
the remote device 52 may be received by the remote networic controller 20. At step 718, 
data is accumulated within the host data controller 22 receive data routine (see. Fig. 12, 
step 716) until a fiill packet of information is received. Thereafter, at step 720, the packet 
is identified as either session oriented or monitor oriented data. The identified data 
packet is then returned, at step 722, to the mobile interface 24 and sent to the wired 
communication network 10 via the remote network controller 20. 

Referrin g now to Fig. 13, in accordance with an aspect of the present invention, 
there is illustrated a block diagram of the basic components of the host data controller 22 
(see, e.g.. Fig. 2) of the present invaition. The host controller 22 may be physically 
cormected external to the remote network controller 20 via the mobile interface 24, The 
host data controller 22 is specifically designed to convert the radio infirastructure 56 
protocol to the internal protocol of the remote network controller 20. Typically, one host 
data controller 22 may be connected to each mobile interface 24; however, one or more 
host data controllers 22 may be cormected for redundancy and greater reliability. 

As shown in Fig. 13, the host data controller 22 may comprise an RF 
communications interface module 80, a remote network controller communications 
interface module 78, and a configuration and monitoring module 82. The host data 



CA 02303987 2000-03-16 



P1705LS01 -25- 

controUer 22 may comprise any combination of hardware and software to perform the 
functions described herein. For example, the host data controller 22 may comprise a 
commercially available processor or multi-processor with overlying ^plication software. 
The software running in the host data controller 22 may be written in Z80 -or other 
appix)priate high-level language (e.g., Pascal). The host data controller 22 may also 
contain a plurality of serial ports for commimicating with other devices. 

The remote network controller comraunicatiorjs interface module 78 is connected 
to the mobile interface 24 of the remote network controller 20 and is responsible for 

sending and receiving data to and jfirom the remote network controller 20. A subsystem 

I- 

port 76 (e.g., an RS-232 adapter) may be used to connect the remote network controller 
communications interface module 78 to the mobile interface 24 of the remote network 
controller 20. [f the host data controller 20 is cormected to more than one remote network 
controller, then additional subsystem port connection(s) may also be provided to connect 
to the interface module 78 to the additional remote network controllers. The remote 
network controller communications interface module 78 sends health and status 
information regarding the host data controller 22 to the mobile interface 24. This 
information informs the remote network controller 20 that the host data controller 22 is 
operational and accepting data. 

The configuration and monitoring module 82 is specific to the type of radio 
infrastructure 56 employed. Software parameters, such as the number of subsystem ports, 
how often to send health and status requests, and a list of mobile data controllers 54 to 
which the host data controller 22 can communicate, may be set and stored in the 
configuration and monitoring module 82. The configuration and monitoring module 82 
can also accumulate statistics which are passed to the mobile interface 24. 

In ordei' to diagnose potential system errors in the host data controller 22, the 
remote network controller 20 may test and analyze the host data controller 22 over a 
diagnostic port (not shown) to determine a cause of the system failure or error. The 
diagnostic port may be used not otdy to determine if the host data controller 22 is 
operational, but also to configure software parameters particular to the type of radio 
infrastructure 56. These parameters can be changed to communicate with a different 
radio infrastructure 56 type as necessary. 
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The RF communications interface module 80 is responsible for sending and 
receiving the radio-frequency transmissions. The RF communications interface module 
80 is specific to the radio infrastructure 56 in use and is connected to the radio 
infrastructure 56 by a conununication line 57. Again, because the host data controller 22 
is designed to integrate with an existing radio infi^stmcture 56, each host data controller 
22 is software configured to work with many different types of radio infrastructure 56 
protocols for flejdbiUty, The host data controller 22 may be designed to be plugged into 
the remote network controller 20, connecting to the mobile interface 24, and can simply 
be exchanged with a different host data controller 22, or reprogrammed depending on the 
radio infirastmcture 56 employed. Host data controllers 22 may be configured so as to 
be compatible with, for example, conventional point-to-point radio systems, conventional 
repeater-based radio systems, LTR Tmnking, Motorola Xrunking, Ericsson (ED ACS) 
Tnmking - Voice Path, EDACS RDI Tmnking - Data Path, and EDACS IMC Voice Path 
radio infrastructures. 

Referring to Fig. 14, there is illustrated a block diagram of the components 
comprising the service interface 30 (see Fig. 2) of the present invention. The service 
interface 30 is responsible for communicating to and from the wired communication 
network 10. The service interface 30 is concerned only with the software level protocols 
of the wired communication network 10. The hardware interface to the wired 
communication network 10 is accomplished by a known network control card, such as 
an Ethernet controller or a Token-Ring controller. 

The number of service interfece 30 connections to the wired communication 
network 10 is dictated by the type of wired conmiunication network 10. If the wired 
communication network 10 uses asynchronous data transfer, there will be one service 
interface 30 for every entry point, e.g., serial port, into the wired communication network 
10. In a local area network (LAN) envirormient, each service interface 30 may handle 
a variety of different network addresses. A different service interface 30 may be used for 
each type of wired communication network 10. 

As shovm in Fig. 14, the service interface 30 may include an event handler and 
multithreading dispatcher 90, a process initialization module 92, an inbound daU event 
handler 94, an outbound data event handler 96, a process tenmination module 98 and a 
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wired network interface module 100. The event handler and multithreading dispatcher 
90 may contain liigh-level logic and be used to control the overall execution flow of the 
service interface 30, The process initialization module 92 acquires resources and 
establishes the operation environment of the service interface 30 process. The inbound 
data event handler 94 responds to signals firom the interprocess communication manager 
28 that inbound data is available and preproccss session control information. The 
inbound data event handler 94 may also handle asynchronous timer events. The 
outbound data event handler 96 is provided to respond to signals from wired 
communication network interface module 100 that outbound data is available or that a 
timer event has occurred. The process termination module 98 functions to release 
previously-acquired resources and tenninate the service interfece 30 process gracefully. 
The wired communication networic interface module 100* handles low-level interaction 
with the associated wired communication network transport mechanism, i.e., 
conununication protocol, being used. 

An exemplary process flow of the event handler and multithreading dispatcher 
90 (see Fig. 14) of the present invention will now be described with reference to Fig. 15. 
At step 800, tiie process begins when the service interface 30 is powered up and 
initialized. At step 802, the process initialization module 92 is invoked (described below 
with reference to Fig. 16). At step 804, the event handler and multithreading dispatcher 
90 waits for an event to occur in response, e.g., to network or remote device activity. 
While the event handler and multithreading dispatcher 90 waits for an event to occur, the 
service interface 30 may be placed in a "sleep" mode to conserve processing power. At 
step 806. once an event occxirs, the event handler and multithreading dispatcher 90 
determines if it is a recognized event Recognized events may include Initialize, Send 
Data, Receive Data and/or Terminate. If the event handler and multithreading dispatcher 
60 determines it is not a recognized event at step 806, then processing returns to step 804. 
If the event handler and multithreading dispatcher 90 recognizes the event at step 806, 
then processing continues at step 808, where the event handler and multithreading 
dispatcher 90 determines if the data was received from the host communication network 
10. 
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At step 308, if the event handler and multithreading dispatcher 90 determines the 
data was received from the host wired communication network 10, the event handler and 
multithreading dispatcher 90 invokes the inbound data event handler 94, at step 814 
(described below with reference to Fig. 17) and, thereafter, processing continues at step 
804. If at step 808 the event handler and multithreading dispatcher 90 determines that 
the data was not received firom the host wired communication network 10, the event 
handler and multithreading dispatcher 90 then determines if the data was received from 
the mobile interface 24 at step 810. 

If the e\'erit handler and multithreading dispatcher 90 detemiines at step 8 1 0 that 
the data was received from the mobile interface 24, then at step 816 the outbound data 
event handler 96 is invoked (described below with reference to Fig. 18) and, thereafter, 
processing continues at step 804. If the event handler and multithreading dispatcher 90 
at step 810 deteraiines that the data was not received from the mobile interface 24, then 
at step 812 the event tiandler and multithreading dispatcher 90 determines if there is a 
process termination request. 

If^ at step 812, the event handler and multithreading dispatcher 90 determines 
there is a process termination request, then at step 818 the process termination module 
98 is invoked (described below with reference to Fig. 19). However, if at step 812 the 
event handler and multithreading dispatcher 90 determines that there is not process 
termination request, then processing returns to step 804 to wait for another event 

Referring now to Fig. 16, there is illustrated an exemplary flow chart describing 
the process flow of the process initialization module 92 (see, e.g.. Fig. 14) of the present 
inventioiL At step 820, the interprocess communications interface is setup when the 
service interface 30 is started or powered up. At step 822, the operating envirormient 
parameters are parsed and processed (i.e., the parameters of the operating environment 
are processed individually). At step 824, any resources required (e.g.. memory) are 
acquired. Thereafter, at step 826, the wired communication network interface module 
100 is invoked (see Figs. 20-24 discussed below). As discussed below, the wired 
communication network interface module 100 may include several procedures associated 
with initializing the cormectivity with the wired commimication network 10. reading data 
from the wired commurucation network 10, writing data to the wired communication 
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network 10, and terminating cxmnectivity with the wired communication network 10. In 
accordance witli an aspect of the present invention, a imique set of procedures may be 
provided by the wired communication network inter&ce module 100 for each type of 
wired communication network 10. For example, a unique set of procedures may be 
provided for networks utilizing transparent asynchronous communications, TCP/IP 
stream sockets. Vehicle Location Reporting Facilities, Bidirectional Messaging Facilities, 
or Credit Card V erification Facilities. 

After the wired communication network interface module 100 is invoked, the 
results of the pnjvious operations performed at step 826 are sent at step 828 to the mobile 
interface 24. Ac step 830. it is determined by the process initialization module 92 if the 
wired communication network interface module 100 was successfully invoked at step 
826., If it is determined at step 830 that the wired communication network interface 
module 100 was successfiiUy invoked, then the initialization is complete at step 832, and 
processing returns to step 804 in Fig. 15. If, however, it is determined at step 830 that 
the wired commimication network interface module was not successfully invoked, then 
the service interface 30 is terminated at step 834. 

Referring now to Fig. 17, there is illustrated an exemplary flow chart of the 
processing stqjs for the inbotmd data event handler 94 (see, e.g.. Fig. 14) of the present 
invention. At step 836, the inbound data event handler is invoked (from step 814 in Fig, 
15). At step 838, the data portion of the message sent by the wired communication 
network 10 is extracted. At step 840, the service interface 30 requests a packet of data 
from the mobile interface 24. At step 842, after the packet is accepted by the service 
interface 30, data is sent to the appropriate destination via the wired conununication 
network 10. The inbound data event handler 94 then waits for a disconnect request at 
step 844. If the inbound data event handler 94 receives a disconnect request at step 844, 
then a discormect command is sent to the mobile interface 24 at step 846. Processing 
then continues at step 804 in Fig. 15. If, however, the inbound data event handler 94 
does not receive a disconnect request at step 844, then the request received is ignored at 
step 848 and, thereafter, processing then continues at step 804 in Fig. 15. 

Referring now to Fig. 18, there is illustrated an exemplary flow chart of the 
processing steps for the outbound data event handler 96 (see Fig. 14) of the present 
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invention. At step 850, the outbound data event handler is invoked (from step 816 in Fig. 
15). At step 852, the outbound data event handler 96 determines if there is a request 
(e.g., a discoim<:ct request from the wired communication network 10 or the remote 
device 52). If there is a request, then processing continues at step 856. However, if there 
is presently not a request, then at step 854 the outbound data from the network 10 is sent 
to remote device 52 via the mobile interface 24. At step 865, the outbound data event 
handler 96 then determines if a disconnect request has been received. If the outbound 
data event handler 96 receives a discormect request at step 856, then a discormcct 
command is sent to the mobile interface 24 at step 860 by the interprocess 
communication manager 28 (see, e.g.. Fig. 2). Processing then continues at step 804 in 
Fig. 15. If, however, the outbound data event handler 96 docs not receive a disconnect 
request at step 8 56, then the request received is ignored at.5tep 862 and processing then 
continues at stq) 804 in Fig. 15. 

Referring now to Fig. 19, there is illustrated an exemplary flow chart of the 
processing steps for the process termination module 98 (see Fig. 14) of the present 
invention. At step 864, the process termination module 98 is invoked (from step 818 in 
Fig. 15). At ;itep 866, the wired communication network interface module 100 
connection is closed. Thereafter, at step 868, the processes associated with the service 
interface 30 are terminated. 

Referring now to Figs. 20-24, there are illustrated exemplary flow charts of the 
various processes that may be performed by the wired communication network interface 
module 100 of the present invention. The wired communication nctworic interface 
module 100 imiy consist of a number of discrete fimctions which provide the service 
interface 30 with a uniform means of conununicating with various host computer 
networks, irrespective of the communication protocols of the wired communication 
network 10. All protocol and other feature-specific communications translation and 
handling is performed at the wired communication network interface module 100. The 
wired communication network interface module 100 may be designed for networks 
utilizing differemt implementations, such as transparent asynchronous corrununication, 
Hayes compatible communication, TCP/CP stream socket, Bidirectional Messaging 
Facilities, File Transfer Facilities, SNA Protocol Enveloping, Vehicle Location Reporting 
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Facilities, Credit Card Verification Facilities, and Harris DNP 3.0 Frame Relay. As 
noted above, a unique set of procedures may be provided by the wired communication 
networic interfiice module 100 for each type of wired communication network 10. 
Examples of several of these sets of procedures are provided below. 

Referring now to Fig. 20. there is illustrated an exemplary flow chart of the set 
of procedures associated with the wired communication network interface module 100 
that are designcKl for transparent asynchronous communication networks. At step 900, 
an initialization process begins in accordance, for example, with step 802 of Fig. 15. At 
step 902, the serial port of the wired communication network 10 that is to be used is 
determined, and the identified port is opened or accessed at step 904. At step 906, the 
speed (bps), the parity (odd or even), and the data bits for communication with the 
network 10 are established along with other appropriate parameters. 

At step 908 a data read operation begins. The data read routine may be invoked 
by the outbound data event handler 96 at step 850 (see Fig, 18). Initially, at step 910, the 
wired communi cation network interface module 1 00 determines if there is data to be read 
fiom the serial port. If at step 910 the wired communication network interface module 
100 determines there is data to be read, then at step 916 the data is added to an 
accumulated data buffer within the remote iietwork controller 20. At step 918, if the 
wired conununication network interface module 100 determines that the data buffer is 
full, then at stej) 9 14 the data accumulated in the buffer is returned to the calling module. 
It however, at step 910 the wired communication networic interface module 100 
determines there is no data to be read fi:om the serial port attached to the network 10, then 
at step 912 it is determined if the inter-character time (e.g., a predetermined character 
receipt delay time) has been exceeded. If at step 912 the inter-character time has been 
exceeded, then at step 914 the accumulated data buffer is returned to the calling module 
to be further processed. Otherwise, if the inter-character time has not been exceeded, 
then processing continues at step 910 so that the wired communication network interface 
module 100 may again deteraune if there is data to be read from the serial port 

At step 920, a write data routine is started. The write data routine may be irutiated 
by the inbound data event handler 94 at step 836 in Fig. 17. At step 922, the data is sent 
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directly to the seirial port of the wired commimication network 10. The write data routine 
is thereafter completed 

At step 924, a terminate routine is initiated. The terminate routine may be 
initiated in accordance with a terminate request at step 818 in Fig. 15. In response to 
initiation of the terminate routine, the serial port of the network 10 is closed at step 926. 
Thereafter, at step 928, the serial port resource is released so it may be used by another 
process. Finally, at step 930, any data buffers in use are also released. 

Referring now to Fig. 21, there is illustrated exemplary flow charts of the set of 
procedures associated with the wired communication network interface module 1 00 for 
networks utilizing TCT/IP stream socket connectivity. At step 932, an initialization 
process begins ui accordance, for example, with step 802 of Fig. 15. At step 934, a host 
network and serial port to be used are determined. At stept-936, an appropriate socket is 
created. At step 938, the socket server is accessed for data transport. 

At step 940 a data read operation begins. The data read routine may be invoked 
the outbound data event handier 96 at step 850 (see Fig. 18). Initially, at step 942, the 
wired commimic-ation network interface module 100 determines if there is data to be read 
fix)m the socket. If at step 942 the wired communication network interfece module 100 
determines there is data to be read, then at step 944 the data buffer is returned to the 
remote network controller 20 for further processing. 

At step 946, a write data routine is started. The write data routine may be initiated 
by the inbomd data event handler 94 at step 836 in Fig. 17. At step 948, the data is sent 
by:* the wired network interface module 100 directly to the socket at the wired 
communication network 10. The write data routine is thereafter completed. 

At step 950, a terminate routine is initiated. The terminate routine may be 
initiated in acairdancc with a terminate request at step 818 in Fig. 15. Initially, the 
socket is closed at step 952. Thereafter, at step 954. the socket resource is released so it 
may be used by another process. Finally, at step 956, any data buffers in use are also 
released. 

Referring now to Fig. 22, there is illustrated exemplary flow charts of the set of 
procedures associated with the wired communication network interface module 100 for 
use with networks utilizing Vehicle Location Reporting Facilities. At step 958, an 
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inidaiization process begins in accordance, for example, with step 802 of Fig. 1 5 . At step 
960 the wired commxinicaticn network interface module 100 determines a position 
recording file to be used to record data. The position recording file may be stored within 
the wired communication network 1 0. At step 962, the position recording file is accessed 
from the network 10. Thereafter, at step 964, the recording interval is placed into a read 
buffer that may be provided to the remote device 52 via the mobile data controller 54. 

At step 966 a data read operation begins. The data read routine may be invoked 
by the outbound data event handler 96 at step 850 (see Fig. 18). Initially, at step 968, the 
wired conmiuiiication network interface module 100 determines if there is data in the 
read buffer. If at step 968 the wired communication network interface module 100 
determines thenj is data in the read buffer, then at step 970 the contents of the read buffer 
is returned to the calling module. 

A^gi^§72> a write data operation is started. The write data routine may be 
initiated by the inbound data event handler 94 at step 836 in Fig. 17. Initially, at step 
974, the wired communication networic interfece module 100 determines if a fiill Global 
Positioning Satellite (GPS) message has been accumulated. If at step 974, the wired 
conomunication network interfece module 100 determines that a fiili GPS message has 
not been accumulated, then no action is taken at step 980. If at step 974, the wired 
communication network interface module 100 determines that a full GPS message has 
been accumulaled, then the message is converted at step 976 to a standard form usable 
by the wired communications network 10. At step 978, the position recording file at the 
host is appended with the GPS message. 

At step 982, a terminate routine is initiated. The terminate routine may be 
initiated in accordance with a terminate request at step 818 in Fig. 15. The terminate 
routine may comprise closing the position recording file at step 984. 

Referring now to Figs. 23A and 23B, there is illustrated exemplary flow charts 
of the set of p rocedures associated with the wired cormnunication networic interfece 
module 100 diat are designed for networks utiUzing Bidirectional Messaging Facilities 
or Store and lorward Messaging Facilities. Referring to Fig. 23A, at step 986, an 
initialization process begins. The initialization process may be started in accordance, for 
example, with step 802 of Fig. 15. At step 988, a message queue for the remote device 
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52 is accessed. Thereafter, at step 990, if no queue exists for the remote device 52, a 
message queue is created at the remote network controller 20. 

At step 992 a data read operation begins. The data read routine may be invoked 
by the outbound data event handler 96 at step 850 (see Fig, 18). Initially, at step 994, the 
wired commmtication network interface module 100 determines if a message is in the 
process of being sent. If at step 994 the wired communication network interface module 
100 determine:; that a message is being sent, then at step 998, the current message 
segment is sent by the remote device 52 to the wired communication network 10. If at 
step 994 the wired communication network interface module 100 determines that no 
message, is being sent, then at step 996, the wired commimication network interface 
module 100 d'Stermines if there is a message queued. If at step 996 the wired 
communication network interface module 100 determines that no messages are queued 
then no action is taken. However, if at step 996 the wired communication network 
interfece module 100 determines that there is a message queued for the remote device 52, 
then the current message queued is sent at step 998. After the last segment of the 
message is sent, the wired conununication network interface module 100 may indicate 
that delivery of the message is pending to the remote device 52 at step 1000. 

At step 1002, a write data routine is initiated. The write data routine may be 
initiated by the inbound data event handler 94 at step 836 in Fig. 17. Initially, at step 
1004, the wired communication network interface module 100 determines if a new 
message is present If at step 1004 the wired communication network interface module 
100 determines that a new message is present, then at step 1010 the wired communication 
network inter&:e module 100 starts a new queue entry. Thereafter, processing continues 
at step 1006, where the message segment is recorded. At step 1008, the wired 
communicatioE. network interface module 100 determines if this is the last segment. If 
at step 1008 the wired conomunication network interface module 100 determines that it 
is the last segment, then at step 1012, the queue entry is closed and "Message Received" 
message may be placed into the read buffer at step 1014 to be sent to the remote device 
52. If at step 1008, the wired communication network interface module 100 determines 
that it is not the last segment, then no action is taken. 
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Referring to Fig. 23B, at step 1016, a terminate routine is started. The termbate 
routine may be :initiated in accordance with a terminate request at step 8 18 in Fig. 1 5. At 
step 1018, the wired communication network interface module 100 determines if the 
terminate request has come in the middle of a message. If at step 1018, the wired 
5 communication network interfece module 100 determines that the request came in the 

middle of a message, then the message is purged at step 1022. Processing then continues 
at step 1020, waere the wired communication network interface module 100 closes the 
message queue. 

Refenring now to Fig. 24, there is illustrated flow charts of the set of procedures 
10 associated with the wired communication network interface module 1 00 designed for use 

with networks utilizing Credit Card Point-of-Sale Facilities. At step 1024, an 
initial iz a ti on process begins. The initialization process may be started in accordance, for 
example, with step 802 of Fig. 15. In accordance with the invention, no action is required 
for the initializ:ition procedure. 
15 At step 1 026 a data read operation begins. The data read routine may be invoked 

the outbound d;ita event handler 96 at step 850 (see Fig. 18). Initially, at step 1028, the 
wired commurication network interface module 100 determines if there is a response 
from a server attached to the wired communication network 10. If at step 1028 the wired 
communication network interface module 100 determines there is a response from the 
20 server, then at rjtep 1030 the response is read, and the response buffer is returned to the 

remote device 52 at step 1032. If at step 1028 there is no response fix}m the server, then 
nonaction is taken. 

At step 1034. a write data operation is started. The write data routine may be 
initiated by the inbound data event handler 94 at step 836 in Fig. 17, At step 1036, the 

25 wired cormnunication network interface module 100 first determines if a full request by 

the remote device 52 has been accumulated. If at step 1036 the wired communication 
network interfiice module 100 determines that a full request has not been accumulated, 
then the remote: device 52 continues to accumulate a request at step 1042. If at step 1036 
a full request has been accumulated, then at step 1038, the request is formatted for the 

30 server on the vnrcd communications network 10. Thereafter, the request is placed into 

the server file :it step 1040. 
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At step 1044, a terminate routine is illustrated. The terminate routine may be 
initiated in accordance with a teraiinate request at step 8 1 8 ia Fig. 15. According to the 
present invention, no action is necessary for the terminate routine. 

Referring now to Fig. 25, there is illustrated a block diagram of the various 
components of Ihe mobile data controller 54, according to another aspect of the present 
invention. The mobile data controller 54 may be specifically designed to match the 
asynchronous data transferred to and firam the remote device 52 to the radio infrastructure 
56 protocol. T^'pically, there is one type of mobile data controller 54 that is associated 
with a host data controller 22 which is cormected to the mobile interface 24 of the remote 
network controller 20. In addition, the mobile data controller 54 may have a unique 
identifier associated with it for routing purposes. 

In accordance with the present invention, the mobile data controller 54 may be 
implemented by any combination of hardware and software. For example, the mobile 
data controller 54 may comprise a commercially available processor with overlying 
software and random access memory. The software nmning in the mobile data controller 
54 may be written in Z80 or other appropriate processor-based (i.e., native) assembly 
language and configured to the specific radio infi:astructure 56. The software may specify 
the various voltage levels and logic signals necessary to communicate via the RF 
communications infirastructure 56. As noted above, the mobile data controller 54 may 
translate and pass any protocols associated with the wired communications network 10 
to and fipom the remote device 52 to make it appear to the wired commimication network 
10 that the remote device 52 is locally-attached. 

The mc'bile data controller 54 is configurable over the radio infi^tructure 56. 
configuration information may be input by an operator at the remote network controller 
20 through the console interface 34 (see Fig. 2) and passed over the radio infrastructure 
56 to the mobile data controller 54. This allows parameters such as packet size to be 
changed at the host wired communications network 10 without the necessity of altering 
the mobile datit controller 52 in the field. 

As shown in Fig. 25, the mobile data controller 54 may comprise an RF 
communications interface module 106, a remote device communications interface 
module 102, and a configuration and monitoring module 104. The mobile data controller 



CA 02303987 2000-03-16 



P17051.SOI -37- 

54 may be connected to the remote device 52 via a communication port 108 for sending 
and receiving clata. The remote device communications interface module 102 is 
connected to the remote device 52 via the communication port 108 and is responsible for 
sending data to, jmd receiving data from, the remote device 52. The communication port 
108 -may comprise, for example, an RS-232 adapter. 

The cortfiguration and monitoring module 104 is specific to the type of radio 
infrastructure 56 employed. Software parameters, such as the number of subsystem ports, 
how often to send health and status requests, and a list of host data controllers 22 to 
which the mobile data controller 54 can communicate, may be set and stored in the 
configuration aiici monitoring module 104. The configuration and monitoring module 
104 can also accumulate statistics which are passed to the host data controller 22. 

In order to diagnose potential system errors in the jnobile data controller 54, an 
operator may be provided with the ability to field test and analyze the mobile data 
controller via an external diagnostic port 1 12 to determine a cause of the system error or 
feilure. The dia.gnostic port 1 12 may be used not only to detennine if the mobile data 
controller 54 is operational, but also can be used to configure software parameters to 
determine the t)pe of the radio infi^tructure 56. These parameters can be changed to 
conmnmicate with a different type of radio infrastructure 56 as necessary. 

The RF communications iaterfrice module 106 is responsible for sending and 
receiving the data via radio-frequency (RF) transmission. The RF communications 
interfece module 106 is specific to the radio infrastructure 56 used, and is connected to 
the radio irtfrastmcture 56 through a conmiimication line 1 10. Becaiise the mobile data 
controller 54 is designed to integrate with an existing radio infiastmcture 56, each mobile 
data controUo* 54 may be software configured, for purposes of flexibility, to work with 
many types of radio infirastructure 56 protocols. The RF communications interface 
module 106 nKiy also send health and status information regarding the mobile data 
controller 54 to the host data controller 22. This information may inform the remote 
network controller 20 that the mobile data controller 54 is operational and the remote 
device 52 is accepting data. 

According to the present invention, the RF communication interface module 106 
may include a commercially available modem (not shown). The modem may be selected 
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dq)cnduig on ths data rate(s) of the communication line 100 and the radio infrastructure 
56. More than one modem may be provided if multiple data rates are required. 
Optionally, the modem can be implemented using a Digital Signal Processing (DSP) chip 
and associated software. The DSP chip can be a conmaercially available programmable 
signal processing chip. In such a case, the DSP implementation will allow a single 
modem to be changed (e.g., by uploading new parameters to the DSP software) in order 
to communicate: with a pluraUty of different types of radio infrastructures 56 having 
distinct protocols and data rates. 

Similar to the host data controllers 22, the mobile data controllers 54 may be 
compatible witti; for example, conventional point-to-point radio systems, conventional 
repeater-based i:adio systems, LTR Trunking, Motorola Trunking, Ericsson (ED ACS) 
Trunking-Voice Path, ED ACS RDI Trunking-Data Path, and ED ACS IMC Voice Path 
based radio infrastructures 56. 

Referring ^ain to Fig. 2, a brief description of the interprocess communications 
manager 28 will be provided According to the present invention, the interprocess 
communications manager 28 is responsible for routing ail communication between the 
various modules and interfeces within the remote networic controller 20, The interprocess 
communications manager 28 creates a logical route fix)m the remote device 52 to the 
service interface: 30 of the remote network controller. The interprocess communications 
manager 28 paajes routing information which determines from which radio infr^tmcture 
56 and remote device 52 the inbound data has come from, and to which radio 
ini^astmcture 56 and remote device 52 the outbound data will be sent 

The interprocess communications manager 28 may also pass information 
generated by tlic remote netwo± controller 20, which is independent of the data and 
routing information. This information may include internal parameters and error 
detection codes. The interprocess commimications manager 28 also interfaces with the 
control process module 26. The control process 26 may act as the "central hub" of the 
remote networl: controller 20. The control process 26 provides resource management, 
process management, session management, configuration management and system 
statistics management within the remote network controller 20. 
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As further shown in Fig. 2, the remote networic controller 20 also includes a 
console interface 34. The console interface 34 may be adapted to allow a network 
operator to coniigure and control the wireless Network Interfaces described above, the 
mobile user characteristics and the configuration information of the wired 
communicatioas network 10. The console interface 34 may be a stand-alone platform 
having a commi;rcially available processor (e.g., an Intel or Motorola based processor) 
and an Ethernet controller card for communicating, for example, with another remote 
network controller 20. 

Referring now to Fig. 26, there is illustrated a remote gateway 120, in accordance 
with another asjiect of the present invention. As shown in Fig. 26, the remote gateway 
120 is comprised of a transparent communications module 122, a field service interface 
module 128, a configuration and health module 124 and^a RF commimications module 
126. The remote gateway 120 is fimctionally similar to the mobile data controller 54, 
However, the remote gateway 120 is a specific type of mobile data controller that may 
be used to attach to a remote telemetry unit for monitoring, for example, electrical power 
distribution. 

The transparent communications module 122 is responsible for communicating 
with a terminal device, typically a Remote Telemetry Unit (RTU) located in the field, and j 
accepts data from the RF communications module 126. As shown in Fig. 26, the 
transparent communications module 122 may be connected to a RTU 133 via a 
communication line 130. The transparent communications module 122 does not 
recognize any p:rotocol, but handles hardware flow control and buffering and packetizing. 
Data commimication between the transparent communications module 122 and the RTU 
133 may be carried through asynchronous serial transfer. 

The RF conununications module 126 is configured to communicate with the 
remote network controller 20 using whatever protocol is required for data transport over 
the radio infi^stmcture 56. The RF commimications interfece module 126 interfaces with 
the radio infiastructure 56 in a similar manner as previously described above with regard 
to the RF communications interface module 106. The RF communications interface 
module 126 accepts data from the transparent communicarions module 122 and dehvers 
it to the radio iafi:^tructurc 56 for transmission to the remote network controller. The 
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RF communicalions interface module 126 detects collisions with inbound RF data and 
restarts outbound transmissions. The RF communications interface module 126 perforaas 
error/retry fimctions and notifies the transparent communications module 122 of 
successes or failures. 

The field senrice interface module 128 allows a technician to field test the remote 
gateway 120 and troubleshoot the remote gateway should a system enror or problem arise. 
An external diaj^ostic port 112 cormected to the field service interface module 128 may 
be provided for this purpose. The field service interface module 128 may interact with 
the configuration and health module 124 to query, set, and reset local configuraUon of the 
remote gateway 120. 

The configuration and health module 124 may accept configuration information 
from the remote networic controller 20 via the radio inftastructure 56 and adjust the 
operating parameters of the remote gateway 120 accordingly. The configuration and 
health module 124 may also monitor and determine if the RF commurucations module 
126 has successfiiUy transmitted a packet of information to the host data controller 22 by 
analyzing the data stream. If a packet of information has not been successfully 
transmitted, the configuration and health module 124 may direct the RF commimications 
module 126 to xesend the packet of information to the host data controller 22. 

Referring now to Figs. 27 and 28, there is illustrated a block diagram of an 
integrated remote network controller 140 according to another aspect of the present 
inventiort The components of the remote network controller 140 that are similar to that 
discussed above with respect to Fig. 2 are designated with the same reference numeral 
and also with a prime (" ' ") added thereto. 

As sho'vn in Fig. 27, the remote network controller 140 according to another 
aspect of the present invention may include one or more service interfaces 30', an 
interprocess communications manager 28*, a control process 26\ one or more mobile 
interfaces 24', and a subsystem synchronization processor 150 which is used to link one 
or more remote network controllers 140 together (see Fig. 28). As further shown in Fig, 
27, one or mors host data controllers 22* are connected to the mobile interfaces 24' and 
provided externally to the remote network controller 140. The number of host data 
controllers 22* and mobile interfaces 24* may be dependent on the number of radio 
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infrastructures 56 present. In addition, the number of service interfaces 30* may be 
dependent on the number and type of wired communications networks 10 present. 

Accordiig to an aspect of the present invention, two remote network controllers 
140 may be linJ<:ed by a local netwo± 152 (see Fig. 28). This configuration provides a 
redundant system which insures greater reliability of communication between the remote 
device 52 and the wired communications network 10. For example, should any particular 
component fail, such as a host controller 22' or an interprocess communications manager 
28', the remote device 52 can still communicate with the wired communication network 
10 because of the redundancy of the components of the remote network controllers 140 
provided. 

There are two main implementations of this system according to the present 
invention. With, the first implementation, only one of the remote network controllers 140 
is operating at any given time. Should the operational remote network controller 140 feiU 
the other remottj network controller 140 may unmediately take its place. For example, 
if remote network controller "A" fails, then remote network controller "B" may be 
activated to take its place. 

Under tlie second implementation, a distributed processing scheme is utilized and 
both of the remote network controllers 140 are operated at the same time. According to 
the distributed processing scheme, the processing load (e.g., event handling and data 
transfer) may be distributed among the operational remote network controllers 140. 
Should a particular remote network controller 140 (e.g., controller "B") fail, the 
reiijaining operational remote networic controller 140 (e.g., controller "A") will handle 
the entire processing load. 

The above-mentioned distribution of the processing load is generally a fimction 
of the radio inlrastnicture 56, and not the processing capacity of the remote network 
controllers 140. This is because performance increases are mainly based on the number 
of available communications channels, rather than the raw processing capability of the 
remote networic controllers 140 attached to the wired commuiucations network 10. For 
example, if the radio infrastmcture 56 is a trunking radio network with five channels, it 
is possible for Jill five channels to be simultaneously allocated and used by the remote 
network controllers 140. On the other hand, if there is only one channel available in the 
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radio infrastnictiire 56, then only one remote network coatroUer 140 can access the radio 
infrastructure 56 at a time; as a result, no performance gain may be realized by employing 
multiple remote networic controllers 140 when only limited channels are available. 

As illusTated in Fig. 28, the local network 152 is used to connect the remote 
network controllers 140 together. The local network 152 may be, for example, an 
Ethernet local Jtrea networic Each of the remote network controllers 140 includes a 
subsystem synchronization process module 150 that is connected to the local network 
152. Two separate console interfaces 34' may also be attached to the local network 152. 
Each console ini;erfece 34' may be attached to the local network 152 to allow an operator 
to conJSgure ancrcontrol a particular remote network controller 140. 

The sub<;ystem synchronization process module 1 50 may be implemented through 
any combination of hardware and software and is respojisible for keeping track of all 
routing tables 2ind health and status information associated with both of the remote 
network controllers 140. Each subsystem synchronization process module 150 is 
connected to an interprocess conmiunications manager 28* of one of the remote network 
controllers 140 ;md may access all routing tables and health and status information with 
respect to the remote network controller firom the interprocess communications manager. 
The health and irtatus information and routing tables maybe periodically updated based 
on the status of ;md events present at the remote network controller 140. The periodically 
updated health and status information and routing tables may then be shared with the 
other subsystem synchronization process module 150 via the local network 152 so that 
the-tables and information associated with both of the remote network controllers 140 is 
maintained in each of the subsystem synchronization process modules 150. Since the 
tables and information are periodically updated, a synchronization routine may be 
provided so that the information and tables are sent to the respective subsystem 
synchronization process modules 150 at predetermined intervals. If a particular 
subsystem synchronization process module 150 does not send or receive the tables and 
information, or if a particular subsystem synchronization process module 150 sends 
information indicating that one of the remote network controllers 140 has malfunctioned, 
the other subsystem synchronization process module 150 may reroute any existing 
cormections to the host data controllers 22' and to the wired network 10 of the 
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malfunctioning remote network controller 140 to the remaining operational remote 
network controller 140. 

As furth'jr shown in Fig. 28, the host data controllers 22* have two ports, 154 and 
156, that are connected to a different remote network controller 140. As in Fig. 2, the 
remote network controller 140 commtmicates to the host data controller 22* and sends 
health and status infonnation through the ports. If the host data controller 22* does not 
receive information that one of the remote network controllers 140 is operational, the host 
controller 22* can switch ports, e.g., from port 154 to port 156, in order to communicate 
with the other n;nlote networic controller 1 40. 

While tlie invention has been described with references to several exemplary 
embodiments, it is understood that the words which have been used herein are words of 
description and illustration, rather than words of limitation. Changes may be made, 
within the purview of the appended claims, without departing from the scope and spirit 
of the invention in its aspects. 

For example, although Fig. 28 only shows two remote network controllers 140 
that arc connected by a local network 152, it is possible to connect two or more remote 
network controllers by the local network 152 to provide increased redimdancy. In 
addition, a plui-aUty of local networks 152 may be provided to coimect the remote 
network controllers. Other modifications to the present invention may include selectively 
processing inbound and outbound data in a different logic order and/or by diSerent 
components. In accordance with such a modification, processing fimctions may be 
performed only by the control process, or in the interprocess conmiunication manager 
Another application may be combining the mobile interface with a host data controller, 
and placing the integrated unit within the remote netwo± controller. 

Referring now to Fig. 29, therein is illustrated a general overview of another 
embodiment of the present invention which includes a mobile Router 200 in accordance 
with an aspect of the present invention. The Router 200 provides the mobile application 
or device 52 wiiii the capability to selectively transmit and receive data over a plurality 
of radio frequer.cy infiastmctores 56 and/or the public switched telephone network 58 in 
accordance witli user configured parameters. 
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Referring now to Fig. 30, therein is illustrated a schematic block diagram of the 
mobile Router 200. In the following description of the Router 200, each of the elements 
will be initially generally described and in greater detail thereafter. As shown in Fig. 30, 
the mobile application or device 52 may be attached to multiple Networks by the Router 
200 through Networic Interfaces 214A-D, a Router Core 204, and a Switch 212. The 
Network Interfeices 214A-D provide connectivity for data between the Switch 212 and 
the various Networks infrastructures (e.g., radio infrastructures 56 and public switch 
telephone network 58) through which the mobile device or ^plication 52 connects to 
the communications network 10 (see Fig. 1). The Switch 212 is actuated by the Router 
Core 204, and sends data to a fixed host application or device (e.g., RNC 20) via the 
selected netwoirk. The Network Interface 214 provides information to the Network 
AvailabiUty process 210, which sends this inforaiacion to tjie Decision process 206. The 
Decision process 206 operates in accordance with User Configured parameters 208 which 
specify when and through which Network the data is to be transmitted. The decision 
process 206 monitors the User Configuration parameters 208, and the Network 
Availability 210. When the Decision process 206 (in accordance with User 
Configuration 208 parameters) specifies that a Network (e.g.. Network 3) different than 
the Network cuiTently in use (e.g.. Network 1) should be used, the Decision process 206 
checks the Netv/o± Availability 210 for the particular Networic to be switched to. If the 
Network is available, the Decision process 206 instructs the Router Core 204 to switch 
to the new Network. The Router Core 204 then updates routing tables (not shown) 
maintained within the Router Core 204 to reflect the new data path, and acmates the 
Switch 212 to connect to the new Network. Data may then flow over the new Network. 
In accordance vath an aspect of the present invention, data may flow inbound to the fixed 
host through one Network, and outbound to the remote mobile Application or device 52 
through the same Network, or through a different Networic 

With reference to Fig. 30, the mobile application or device 52 may comprise a 
software appUcation rujaning on a portable or laptop computer performing a variety of 
fimctions as programmed by the software application (e.g., database services). The 
Application or device 52 may also comprise a special purpose device designed to perform 
a particular function, such as a credit card reader or barcode scanner. The Application 
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or device 52 in:iy generate a data stream which is sent to a fixed location (e.g., a host 
computer infrastructure 10). 

An exemplary application nmning on the mobile device 52 is a mobile remote 
client application which provides the remote user with the capability to send and retrieve 
data fix)m a fixed database server application. The data may consist of customer records 
which, for example, may be used by service personnel operating a fleet of vehicles to 
service customers scattered about a wide geographic area. In the exemplary application, 
the mobile client application may request customer records firom the fixed database 
server, and disjilay the records for viewing by mobile service persoimel. The mobile 
client application may send updated records to the fixed database as the service persormel 
finish assigned tasks. The updated records may contain a service history, equipment 
upgrades, and repairs for each customer. 

Another exemplary application nmning on the mobile device 52 may be a client 
application which retrieves a Ust of dispatched jobs to be performed by the service 
persoiuiel during each day. The jobs may be uploaded to the remote mobile device 52 
each morning and stored In another client application in the mobile device 52. As the 
service persormt^l change job locations, the status of each job may be updated to indicate 
a status, e.g., en route, arrived and finished with comments. The status may be sent fipom 
the application to the fixed home office, so a dispatcher at the home office is aware of the 
locations of service persoimel in the field. 

Byway of non-limiting examples, the mobile device 52 may comprise a portable 
oriaptop computer, a computer having an embedded Router 200; a terminal or terminal 
emulator, a dats. gathering device (e.g., a SCADA system or remote telemetry system for 
obtaining data from a remote location for forwarding to a central location for processing); 
a card-swipe reader device (e.g., credit/debit/bank cards) for use in a mobile billing 
application, such as a taxi or mobile food cart; a smart-card reader, a logging device, such 
as those used in a package delivery system or fleet; a device for reading bar codes (e.g., 
for inventory control); and a remote appUcation with data to send or to receive, from a 
fixed application or device (e.g., remote diagnostic tool). The above-noted applications 
arc provided merely for exemplary purpose, and other applications and mobile devices 
52 may be used with the Router 200 of the present invention. 
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Typically the device or Application 52 sends and receives data using a variety of 
protocols (e.g.. Internet Protocol (IP) / transparent (via MDC 54) / ack-nack, etc.). The 
use of a variety/ of protocols provides for open transport of data throughout many 
networks, and in particular, networks which support open standards such as IP. However, 
many proprietary networks which require interfece and/or protocol translation remain in 
use. In the Router 200 of the present embodiment, the function of interfacing with 
networks and protocol translation may be performed by the NetwG± Interfiaces 2 1 4A-D. 

According to another aspect of the invention, other types of devices may be 
coimected to the Network Interface 214. Such devices may be used for functions other 
than data and voice communication. By way of non-limiting examples, these devices 
may include Global Positioning System (GPS) receivers and application processors. 

The Router Core 204 is a function which shuttles messages between the 
Application or JDevice 52 and the various Networks. In accordance with the present 
embodiment, the router Core 204 may control which network of a plurality of usable 
network messages are to travel over, and connect access ports (described below) to each 
Network and th(j Application or Device 52. 

The Router Core 204 may also comprise a list of all possible "names" or 
"addresses" to M'hich data may be sent, or from which data may be received. The local 
"names" or "addresses" of the Router Core 204 are stored in tables within a memory (not 
shown) of the Router Core 204. Thus, the Router Core 204 may serve as a 
communication:! "address book" for the Router 200 of the present embodiment The 
Router Core 20^4- also checks all messages passing through, and decides, based on the 
address and/or name entries in the tables, if the message is relevant to the attached 
Application or Device 52, or to the fixed host (e.g.. RNC 20). The address of the fixed 
host may be stored in the Router Core table as well. In accordance with the table entries, 
received messages may be determined to be valid or invalid. The Router Core 204 may 
also actuate the Switch 212 in accordance with the output of the decision process 206. 
The Switch 212 is actuated such that incoming and outgoing messages can be sent 
through the "current" network, as determined by the decision function 206 (to be 
described below). 
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Thc Switch 212 may comprise a message multiplexor, i.e., the Switch 212 
perfonns a one-to-many function for in-bound messages (to the fixed hosts), and a 
"many-to-one" f jnction for outbound messages (from the fixed host). As noted above, 
the appropriate network selection is made by the Routdr Core 204 in accordance with the 
output of the decision process 206. Messages travel through the Switch 212, the Router 
Core 204, and tfcie current Network Interface 214. 

Referring to Fig. 32, the Switch 212 may be implemented using a combination 
of hardware (e.g., multiple electronic ports, one per Network Interface 214) to perform 
the physical connection process 212B, and software (e.g., handlers which are interrupted 

1:, 

at each character to move the character to either the Router Core 204 (outbound), or to 
the current Network Interface 214 (in-bound)) to perform the switch logic process 212A. 

As a non-limiting exemplary hardware implemontatioa, the Switch 212 may 
comprise an 80386EX microprocessor, running at 33 MHZ, 256 kilobytes of FLASH 
ROM, 512 kilobytes of static RAM, six asynchronous serial ports, two TTLnO-RS232 
convertors interfacing with two of the six serial ports directly to compatible devices 
external to the Switch 212, and four internal TTL serial interfeces to internally-mounted 
daughter boards, which carry Network Interfaces 214A-D. Each Network Interface 214 
mounted on a dimghter board may include a power supply for the Network Interface, a 
serial interface to the 80386EX microprocessor, and an interface to the outside network. 
The outside netv/ork may be a radio, a LAN, an antenna (for internally-mounted radios 
in the Network Merface 214 ), or other device accepting or supplying data from/to the 
Router 200, 

the Svs/itching function of the Switch 212 is provided by each serial Network 
Interface port at the 80386EX microprocessor, and the software residing in FLASH 
ROM. The software logic determines which Network Interface to use for transmission 
and receipt of data. The decision is implemented in the Switch, by selecting a physical 
serial port (and therefore which Network Interface) is to be used as the current Network. 
The Decision software in the FLASH ROM instructs the microprocessor to send the data 
to a specific serial port (which is mapped to specific physical addresses within the 
address range of the 80386EX microprocessor). The microprocessor then constructs the 
next message in the message buffers in RAM, and sends the message through the specific 
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serial port whicli is designated as the "current Network" Interface port. The data then 
goes to the Netv/ork Interface (e.g., network interface 214A) connected to that specific 
serial port and o:a to the Network infrastructure. Received data is input to the Network 
InterEace (e,g., netwo± inlerfece 2I4B which may be set to the "current Network" serial 
port) and the microprocessor, where the received data is processed by the microprocessor. 
In accordance v/ith an aspect of the present invention, messages which are received 
through Netwoik Interfaces which are not designated as the "current Network" are 
ignored. 

The Nenvork Interfaces 214A-D are devices which present data to, or obtain data 
from the radio dperating at the various R.F. Network frequencies, bandwidths, and 
modulations. The Network Interfaces 214A-D may provide a port through which 
messages pass, 1o and from the Switch 212. The messages are typically in the fonn of 
a sequence of serial digital bits. The Network Interfaces 214A-D also may provide a 
modulator/demodulator function which transforms the digital data into an analog form 
which may be esisily sent through the R.F. Network voicepath, based on characteristics 
of the assigned frequency band of the R.F. Network. The characteristics of analog 
transmissions are typically bandwidth (in Herts:, or cycles per second), noise present in 
the Network, and assigned frequency of the R.F. Network. Further, the Network 
Interfaces may interface with a radio, which may be included within the Network 
Interface 214, or may be mounted externally to the Router 200 (as shown in Fig. 29). 
The Nctwoiic interface 214 radio interface comprises the actual physical connections to 
the radio for the voicepath data, the muting function (if present and/or required) and the 
fimctionality for issuing a Press-to-Talk to the radio, and for receiving the Transmit Grant 
signal from the i3dio; both are used for handshaking between the radio network and the 
Netwo± Interfai:e 214. This handshaking may be necessary for proper timing of the data 
out onto the RF' NetworL The muting function is used for silencing received signals 
which represent data, rather than voice traffic, which enables a remote user to mute the 
audible noise of the data traffic, which can be annoying to the remote user. 

Examples of Network Interface 214A-D include the MDC 54 and the NovaTel 
Wireless NRM-6812 Cellular Digital Packet Data (CDPD) modem. Where the network 
interfece 214 comprises the MDC 54, the radio is mounted external to the MDC 54, 
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whereas in the MovaTel example, the radio and the network interface are integrated into 
a single unit. 

As noted above, the Network Interfaces 214 provide connections to various types 
of networks. Tliese networks may be wired (for example Public Switched Telephone 
Network 58), o:r wireless (for example Cellular Digital Packet Data (CDPD)). The 
following non-lijniting list includes networks that may be interfaced to the Router 200 
by the Network Interfaces 214A-D: private voice radio including conventional and 
trunked radios (e.g., using MDC 54), Cellular Digital Packet Data (CDPD), Spread 
Spectnmi (e.g., direct sequence and channel-hop), GSM, GPS receiver, satellite 
transponder, RDI (Ericsson) interfece, AMPS, RAM Mobile (Mobitex). RS232, RS485, 
Angel (AT&T), Asynchronous Transfer Method (ATM). Integrated Services Digital 
Network (ISBKl, pubhc switched telephone network (PSTN (POTS) telephone network), 
Ethernet, Ardis, Personal Communications Services (PCS), and any other network which 
is either transparent or operates using a specific protocol. 

The specific protocols to the above-listed networks are implemented in the 
Network Interfiices 214A-D. These protocols may be very different, and therefore 
incompatible with each other. Additionally, a translation device may be provided in each 
Network Interface 2 14 to translate between IP and the particular network protocol By 
providing such a translation device, the AppHcation or Device 52 can use IP data 
regardless of the particular network the AppUcation or Device 52 is actually using. 

Referring to Fig. 3 1, a description of the fimctional components of the Router 200 
will now be deiicribed. The Router 20 may be implemented as an autonomous device 
with multiple cctrmections to the networks through which data is to be routed. The user 
Configuration Jnteriface 208 provides a means >yhereby an external device such as a 
kcyboard/termual may be used to supply configuration information such as preferred 
routes, network node addresses, etc. to the router. Such information is accepted by the 
Configuration Litcrface 208 and is placed into a non-volatile store (e.g., memory) which 
may be queried by other router components. In addition, capability may be provided 
whereby diagnostic information may be requested fi'om the router and sent to the terminal 
device for evaluation by a technician. 
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The Router Core 204 is responsible for making all routing decisions. For a given 
destination netv/ork address specified within a data packet or datagram received &om one 
of the network interface drivers 215A-D, the most-prefeired path will be selected and the 
data packet or datagram forwarded through the preferred netwoiic interface driver 
215A-D. Routing decisions are generally based upon such metrics as network speed and 
interface availability. Other metrics such as destination network, time of day, type of 
data, etc. may also be incorporated into the routing decision. Further^ routing decisions 
may be made at the packet level such that each individual packet of data may be 
transmitted and^or received on different networks in accordance with the user configured 
parameters 208*: 

Exemplary Network Drivers 215A-D may include an Ethernet Driver, a 
Token-Ring Driver, and a Serial PPP Driver. The Ethernet Driver provides a means for 
sending and receiving data through an Ethernet-type network. The fimction of the driver 
is to shield the Router Core from the details of network media access. The Token-Ring 
Driver provides a means for sending and receiving data through a Token-Ring-type 
network. The ifunction of the driver is to shield the Router Core firom the details of 
network media access. The Serial PPP Driver provides a means for sending and 
receiving data through a PPP-based serial data link. The fimction of the driver is to 
shield the Rout sr Core from the details of network media access. Other drivers 2 1 5 A-D 
may be provided to interface with other types of networks as necessary. 

The Network Availability 210 (see also Fig. 30) is a fimction which paiodically 
interrogates each installed Network Interface 214 in the Router 200 and may determine 
if the Network Interface 214 is installed; if the Netwo± Interface 214 is properly 
configured and fimctioning properly; if the Network Interfece 214 is cormected to the 
Network, on-line, and available for sending/receiving messages; and if the Network 
Interface 214 i:5 in good health. The above interrogation process may be accomplished 
by monitoring a timer tick (provided by the switch microprocessor), which instructs the 
Network Availability 210 to query each Network Interface 214. When the timer tick 
occurs, the Network Availability 210 fimction interrogates each Network Interface 214 
as noted above. The status of each Network Interface 214 is then passed to the Decision 
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process 206, which determines what the "next Network" will be if the result of the 
interrogation indicates that the "cuiient Network" is experiencing transmission problems. 

The Nervork Availability 210 of each Network Interfece 214 is determiced in. a 
manner specific to the particular interfaced Network. For example, if the Network is 
CDPD, the Nework Availability 210 interrogates the network to determine if the 
Network Interfiice 214 is currently registered with the Network, and therefore active. 
Also, in the CDPD network, the Network Availabihty 214 determines if the Received 
Signal Strength Indication (RSSI) is sufficient to transmit relatively error-free data. For 
example, in the NovaTel CDPD Network Interface a RSSI of -100 dBm will provide for 
good data transrAission quaUties, Thus, if the Network Availability 210 function queries 
the NovaTel CEiPD Network Interface for the RSSI, and the response is -1 1 0 dBm, then 
the signal is too weak for error-firee transmission, and therefore cannot be used at this 
time. This information is passed to the Decision process 206 to determine if the "current 
Network" should remain the "current Network", and if not, to determine what the "next 
Network" should be. 

The User Configuration 208 block is used to define user configurable parameters 
by which the Router Core 204 selects the "current Network" and the "next Network". 
The Router parameters may include the date and time (e.g., yr-mo-da, hh:mm;ss), and the 
Network Interface 214 installed in each of the internal slots of the Router 200. According 
to the present embodiment there are six internal slots to accommodate Network Interfaces 
to any of private voice radio using e.g., the MDC 54 and a variety of radios, both 
conventional and trunkcd; Cellular Digital Packet Data (CDPD), such as Sierra Wireless 
or NovaTel CDPD modems; spread spectrum, either direct sequence, or channel-hop, as 
Xetron Hunmiingbird spread spectrum modem; GSM, such as Ericsson serial GSM 
module; GPS receiver, such as Motorola VP Encore GPS receiver, or Trimble SVEE Six 
receiver, sateUite transponder, RDI (e.g., Ericsson) interface, implemented via a software 
protocol module and quasi-RS232 interface to radio; AMPS; RAM Mobile (e.g., 
Mobitex); RS232 default and fixed for example in slots I and 2; RS485; Angel (e.g., 
AT&T); ATM; ISDN; PSTN; Ethernet; Ardis; PCS; any other network which is either 
transparent or operates using a specific protocol; and none. Although six slots are 
disclosed herein, other numbers of slots may be provided 
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Other user configurable parameters include: the priority of each intcmal slot, 
(e.g,. 1 to 6) whcxe the slot with priority I is the default startup slot and Network; baud 
rate of each slot (a defisuiit rate may be set to 9600 bits per second, but may be configured 
to be any standaixi baud rate, divisible by 300, up to 1 15.2 kilo bits per second); cost per 
kilobyte per slot (e.g., SO.xx per kilobyte where the least costly slot that is available and 
highest priority will be default); protocol per slot (e.g., none, Point to Point (PPP), Serial 
Line Intemet Protocol (SLIP). Hayes "AT" commands, transparent); slot mode, for 
example, transparent, PSTN, cellular, IP, receive only; slot name or address or phone 
number, slot to be used for diagnostics (e.g., defeult may be set to slot 2); slot muting to 
be used (e.g., none, PL, DTMF, other); number of retry transmissions per Network 
Interface (per slot) before declaration of Network Inter&ce failure (e.g, 0-10); if slot 
Network Interfec;e needs to be configured before it can operate (e.g., y,n); slot to be used 
for remote display (e.g., default may be set to slot 2); slot to be used for Device or 
Application 52 (e.g., a connection to a mobile computer, default is slot 1); and frequency 
at which Network Availability 210 is checked (e.g,, defeult may be set to five seconds). 
Other user configurable parameters may be introduced and configured as necessary. 

The User Configuration 208 function provides the user with the capability to 
instruct the Router 200 how to select a particular Network. These metrics may include, 
but are not limit€:d to: which Netwo± is connected to which Router port, time of day and 
date, priority (switching sequence) of each Network, cost per packet of each Network, 
and preferred default Network, 

: On pow€T up, the User Configuration 208 is checked to determine if it is current. 
If the User ConJiguration 208 is determined to be out of date, the end user is requested 
to input a configuration. The user is notified by blinking LEDs on the front panel or by 
a message sent to the mobile device 52. If the User Configuration 208 is determined to 
be current, no iLser input is requested. 

Further, each Network is continuotisly evaluated for health and connectivity 
status. There ;ire a number of parameters which are examined to determine this, 
including, but not limited to: Received Signal Strength Indication (RSSI), Clear to Send 
(CTS), Channel Clear/Channel Ready, and Transmit Grant. 
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The Decision process 206 coatinuously examines the User Configured parameters 
in the user configuration block 208, to detennine the next Network to use, in case the 
current Network becomes unavailable to send or receive data. Such an unavailability 
may arise becauiw the remote user (and consequently the Router 200) has moved beyond 
coverage of the Netwoiic, or because a problem has occurred with the current Network 
or the Network Interface 214. 

After the Decision process 206 has determined the next Network to use, the 
decision process 206 queries the Network Availability 210. If the next Networic is 
available, then the Decision process 206 updates the routing tables in the Router Core 
204. The Router Core 204 will then actuate the Switch 212 to physically connect the 
next Netwo± as the current Network. 

The Decision process 206 uses the User Configuration 208 parameters defined 
above to detennine the specific criteria for each slot, to be used when deciding if the 
current Networic is to remain the current Network, and if not, what the next Network shall 
be. Once the dtxision process 206 has made a tentative decision to switch to another 
Network (i.e., the next network is to become the current network), it checks the Network 
Availability 210 to ascertain if the Network is actually installed, configured, on-line, and 
in good health. !For example, if the current Network is configured as priority #3, and the 
Network Availability 210 of the priority #2 Network updates to, for example, "installed, 
configured, on-line, and in good health", then the priority #2 Networic becomes the next 
Network. The Decision process 206 will instruct the Switch 212 to switch the priority 
#2 Network to tlie current network. Should the Decision process 206 decide to change 
Networks, it conveys an instruction to the Router Core 204 by instructing the Router 
Core 204 what the next Network Interface 2 1 4 is to be. 

The process of the Decision process 206 checking the User Configuration 208 and 
the Netwo± Availability 210 continues indefinitely, and is described in detail in Figs. 
33-36. Generally, the process helps to guarantee that the mobile user always has access 
to a Network for sending and receiving data. This process also allows what is known 
now as "seamless roaming". This means that the mobile user can move between 
Networks and continue to have reliable data transmission on the different Networks. 



CA 02303987 2000-03-16 



P1705LS01 -54. 

Figs. 33 -36 illustrate the logic of the software in the router. Referring now to Fig. 
33, there is shown an exemplary initialization routine which builds the tables in the 
Router 200. U]pon initialization of the system, at Step 310 the first channel priority is 
checked. At Step 312, it is determined whether or not the first channel is being 
examined. If it is the first channel, at Step 314, table entries for the first channel are built. 
Information wliich is included in the table may be. e.g,, IP address of the destination, 
intervening intmnediate IP addresses, the assigned port, chaimel priorities, and the 
application being used. Typically channel one is assigned the highest priority. After the 
tables are built, the processing increments to the next channel at step 316. From Step 
316, processing ifetums to Step 312. If at Step 312 it is determined that the channel being 
checked is not the first chaimel, processing proceeds to Step 320 to query whether all 
channels have been checked. If all channels have not been checked, processing recums 
to Step 3 14 to continue building the table entries via steps 314 and 316 until all channels 
have been checked. 

Once it has been determined that all channels have been checked, at Step 322 it 
is detemained whether any tables have been built. If no tables have been built, at Step 
324 a configunition error is recognized and the processing stops. Tables may not have 
been built previously, e.g., if there are problems with the EP address, i.e., there was no 
destinadon addi'ess. If at Step 322 it is determined tables were already built, processing 
proceeds to Stqp 326 where all channels are initialized and data transportation begins via 
the Gist channel. 

From Si:ep 326 the processing proceeds to Step 328, also shown in Fig. 35, which 
illustrates an exemplary flow diagram of the Router 200 logic for accounting the Network 
Availability 210 (Fig. 30) and User Configuration 208 (Fig. 30) to decide which chaimels 
to use for data transport. Beginning at Step 328, processing proceeds to Step 330 where 
the chaimel is set to the current channel in a database which is described in more detail 
below. From there, processing proceeds to Step 332 to retrieve the next channel to 
switch to from, the database. The database is stored in flash memory and contains 
configuration information for each channel including how each channel is set up in the 
Router 200 and what configuration values are for each Network Interface 214A-D. In 
addition, the database stores which channel is current and the history of previous current 
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channeis. The tJibles discussed with reference to Fig. 33 at Step 3 14 are also stored in the 
database. 

At step 334 a dctcnnination is made as to whether the previous channel is 
available. Of course if this is the first time through, no previous channel will exist If the 
previous channel is not available, at Step 336 a determination is made as to whether the 
next channel is available. If the next channel is available, at Step 338 a determination is 
made as to whether or not the priority is lower and it is time to switch. The determination 
is made by looldng at the information in the User Configuration 208 (Fig. 30). If it is 
time to switch, at Step 340 a switch to the next channel is made. From there, processing 
continues to stq>-341, where it is detennined if the channel was switched. If the channel 
was switched, processing continues to step 343 where a ping is sent to confirm the path 
is available. From step 343, the processing continues to Step 342, also shown in Fig. 34. 
I£ at step 341, it is determined the chaimel was not switched, processing continues to step 
342. 

Returning to Step 334, if it is determined that a previous channel is available, at 
Step 344 an uiquiry is made as to whether or not the previous channel has a higher 
priority and it is time to switch. The determination is made by consulting the information 
in the User Configuration 208 (Fig. 30). If it is detennined the previoiis charmel is a 
higher priority and it is time to switch, at Step 346 a switch to the previous chaimel is 
made. From Step 346, the processing proceeds to Step 341 as previously described. 

If at Step 344 it is detennined that it is not time to switch and the priority is not 
higher, processing proceeds to Step 336 where it is determined whether the next channel 
is available. If the next channel is not available, at Step 348 the current channel is not 
switched and the processing proceeds to Step 341 as described above. If at Step 336 the 
next charmel is available, then at Step 338 the inquiry into priority and time to switch is 
made as previously described. At Step 338, if it is not time to switch and the priority of 
the next channel is not lower, the Router 200 stays on the current channel at Step 348. 

Refer now to Fig. 34 which illustrates a flow chart of exemplary logic for 
checking the availability of each network interface. Starting at Step 342 processing 
proceeds to Stsp 344 where the status of the chaimel being used is recorded in the 
database. Furttiermore, at Step 344, the Router 200 front panel LED's are updated. If at 
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Step 346 it is determined the availability of all channels has not been checked, at Step 
348 the next channel is identified and at Step 350 the next channeFs availability is polled. 
A channel is not available if it is being used for a mobile device 52 i.e. the channel is 
already one end of the network. If the channel is not available, the processing returns to 
step-348. If the channel is determined to be available at step 350, processing proceeds 
to Step 328 also shown in Fig. 35. 

If at Step 346 it is determined that the availability of all channels has been 
checked, at Step 352 the availability of the present channel is determined. If the present 
channel is avaii;ible, a connection is made at Step 354, If the present chaimel is not 
available, processing proceeds to Step 356 for error handling. The error handling 
procedure is discussed with reference to Fig. 36 below. Upon completion of the error 
handlmg procediore, at Step 360 the channel is set equal to one at Step 362, At Step 350, 
the procedure continues as previously described. 

Refening now to Fig. 36, which is an exemplary flow diagram of the Router 200 
error handling logic, Step 356 continues from Fig. 34. At Step 370, the present channel 
is deemed to be non-available. At Step 372, the next and previous charmels are also 
confirmed to be non-available. At Step 374 an error is indicated to the device or 
^plication. At Step 376 an availability routine is run such as that described previously. 
From the avaiLibility routine at Step 36, the processing continues to Step 360 as 
discussed with reference to Fig. 34. 

The Router 200 of the present invention may be used inside a mobile vehicle, or 
carried by a penjon in a portable apphcation. Further, the Router 200 may be provided 
as an external component connected to a portable device (e.g., a l^top computer) or may 
be implemented within the portable device, such that the portable device and the Router 
200 are provided as one integrated unit. Further, the Router 200 may be used in 
conjimction witli, or integrated into measuring and testing equipment, and transmission 
equipment. S ich a remote device may be needed for very remote monitoring 
applications, such as wildlife studies, etc., necessitating the use of multiple Networks. 

Referring now to Fig. 37, there is shown the software architecture 219 of the 
Router 200 in accordance with an embodiment of the present invention. The architecture 
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is strictly layered in that data flows only vertically between adjacent layers. The 
definition of each layer will now be described. 

The Application layer consists of various processes that perform services directly 
related to the function(s) for which the device is defined. This includes such services as 
de&iing a device configuration, making decisions about which route to select for the 
transport of datit and performing various diagnostic fimctions. 

The Presentation layer consists of a protocol-independent insulating layer 
between the apjjlications and the lower-level networking fimctions. The Presentation 
layer implements a Berkley sockets compliant plication programming interface (API). 

The Networking layer performs all processing related to handling the Internet 
Protocol (IP). The main function of the networking layer in this envirorunent is the 
routing of data passed into the layer fix3m either above or below back out through selected 
Network Interfaces to deliver that data to the intended destination. The relationship of 
destination and network interface is maintained by the Configuration Module and 
Routing Decision Module applications. 

The Dai;a-Link layer provides logical Network Interfaces through which the 
Networking Laj'cr may send and receive data. One or more of these Network Interfaces 
may be active at any time. At least one network interface must be active for the device 
to fimction prctpcrly. The main purpose of the Data-Link layer is to insulate the 
Nctworldng layer fix)m the details of the many link-level protocols used to transport data. 

The De\'ice-Specific layer deals with the details of establishing and maintaining 
data communications through various types of conmiunication devices such as radios, 
modems and data controllers. Each Device-Specific driver handles the vagaries of 
configuring and interfacing with various types of commimication devices while 
presenting a uniform interface to the Data-Link layer. 

The Phj'sical Interfece layer handles the direct interface to external components. 
For example: A serial port driver may handle the sending and receiving of individual data 
bytes through a specific type of serial controller such as an Intel 8250. 

A description of the fimctionality supported by various module blocks as 
presented in Fig. 37 will now be described. 
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The Configuration Module 222 is an Application layer module that allows a 
technician to maintain a database of device configuration information. A technician may 
access the Configuration Module via a diagnostic serial port. Another implementation 
may allow a technician to access the Configuration module through any of the defined 
Network Interfaces via a standard socket 

The Routing Decision Module 220 selects the preferred network interfece through 
which outbound data is transmitted. This decision is based upon a variety of metrics 
including: Interface availability; Time of day; Type of service required; Interface priority 
and others. Exajitples of various routing metric schemes are presented later. 

The TCP^ Socket Interface 224 supports an Application Programming Interface 
(API) which, for example, conforms to the standard Beridey sockets paradigm. Its 
purpose is to shield the Application Layer fiom the details of the underlying networking 
protocols. It allows different network implementations to be employed without the 
applications being required to adapt. 

The TCPHP Router/Gateway 226 implements standard IP host support with the 
additional capability of being able to act as a gateway between multiple networks. IP 
datagrams received by this layer that are not destined for a local IP host address are 
forwarded through the network interfece that is currently designated as the preferred route 
for the given destination address. It is possible that the management and selection of 
preferred routes is implemented by the Routing Decision Module 220 in the Application 
layer. 

The PPP Protocol Driver 228 provides a network interface whose data-link 
protocol confoims to the Point-To-Point protocol standard. The SLIP Protocol Driver 
230 provides a network interface whose data-link protocol conforms to the Serial-Line 
Internet Protocol de facto standard. Other protocol drivers 230 may be implemented 
which provide Network Interfeces which support either existing protocols or fiature 
protocols. The intent is to convey that the underlying link-layer protocol is transparent 
to* the upper and lower layers and that additional protocols may be easily supported. 

The MDC Interface Driver 234 provides device-specific support for Mobile Data 
Controller 54, as described above. The CDPD Interface Driver 236 provides 
device-specific support for a Cellular Digital Packet Data controller. Other 
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device-specific drivers. e.g.. Modem "X" Interface Driver 238 may be impiementcd to 
support current or future devices. 

The Serial Port Driver 240 deals with the hardware aspects of asynchronous serial 
data communications such as manipulating a Serial I/O controller or other such external 
interface. Other physical layer drivers 242 may be implemented which support different 
external interface devices either existing or in the future. 

Although the invention has been described herein with reference to particular 
means, materia!:s and embodiments, the invention is not intended to be limited to the 
particulars disclosed herein; rather, the invention extends to all functionally equivalent 
structures, methods and uses, such as are within the scope of the appended claims. 

For example, the router of the present invention may be included as an internal 
component of tlie mobile device, proving for an integrated mobile device. Optionally, 
the router may be implemented entirely as a software process running on. for example, 
a portable personal computer. In such an implemention, the internal slGt(s) of the 
personal computer may be provided with network interface(s) and a software program 
may serve as the router core. Further, data may be routed to the different networks at 
anotiier level thjm at the packet level. For example, entire messages may be routed over 
various networl:s if such a configuration is required. 
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WHAT IS CLAIMED: 

1. A router for transporting data between a first device and a second device over at 
least one of a plurality' of parallel networks, at least two of the networks being dissimilar, the 
router comprising: 

a first interface for connecting to the plurality of parallel dissimilar networks; 
a second interface for connecting to the second device; and 
a monitoring system that is capable of monitoring the status of the plurality of 
dissimilar networks. 

2. The router of claim L in which the status comprises at least one of installation 
status, network health, configuration status, and network availability. 

3 . The router of claim I , further comprising: 

a system for determining network selection criteria; 

a selector for dynamically selecting at least one of the plurality of networks in 
accordance with the network selection criteria; and 

a switch for switching to the at least one selected network so that data can be 
transported between the first device and the second device over the at least one selected ^ 
network. 

4. The router of claim 3, in which the switch is capable of switching networks 
immediately after transporting a first data packet and before transporting a subsequent 
consecutive data packet. 

5. The router of claim 3, in which the selector is capable of determining a next 
network fi-om the plurality of networks in accordance with the network selection criteria 
when the monitoring system determines that the selected network is unavailable. 

6. The router of claim 5, in which the switch is capable of switching to the next 
network when the monitoring system determines that the selected network is unavailable. 

7. The router of claim 1, in which the networks comprise wireless networks. 

8. The router of claim 1, in which the networks comprise at least one wireless 
network and at least one wireline network. 

9. The router of claim I, fiirther comprising a system for interfacing protocolized data 
into the plurality of dissimilar networks using different protocols. 
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10. The router of claim 1, in which the plurality of networks comprise switched 
networks. 

11. The router of claim 1, in which the plurality of networks comprise dedicated 
networks. 

12. The router of claim 1, in which the plurality of networks comprise switched 
networks and dedicated net^vorks. 

13. The router of claim 1, in which the plurality of networks comprise at least one of 
digital networks and analog networks. 

14. The router of claitp 1, in which at least one of the plurality of networks comprises 
a packet based wireless network, 

15. The router of claim 1, in which the monitoring system determines whether a next 
network is available for data transport. 

16. The router of claim I, in which the data comprises digital data. 

17. The router of claim 16, in which the digital data further comprises digital voice. 

1 8. A method of dynamically routing data between a first device and a second device 

over a plurality of parallel wireless networks, at least two of the networks being dissimilar, j 

t 

the method comprising: 

routing the data through at least one of the dissimilar networks. 

19. The method of claim 18, further comprising monitoring the status of the at least 
two dissimilar networks. 

20. The method of claim 19, further comprising selecting a network to be used for 
data transport based upon the monitoring. 

21. The method of claim 20, in which the selecting occurs when the monitoring 
determines diat the selected network is unavailable. 

22. The method of claim 19, further comprising determining network selection 
criteria. 

23. The method of claim 22, further comprising selecting a network to be used for 
data transport based upon the monitoring and the network selection criteria. 

24. The method of claim 23, further comprising switching to the selected network. 

25. The method of claim 24, in which the switching networks occurs inunediately 
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after transporting a first data packet and before transporting a subsequent consecutive data 
packet. 

26. The method of claim 18, further comprising transporting data via a plurality of 
protocols comprising at least Internet Protocol (IP), and transparent protocol over the 
plurality of networks. 

27. The method of claim 1 8, further comprising transporting data between the first 
device and the second device in accordance with the routing, and detecting and correcting 
errors in transmission of the transported data. 

28. The method of claim 18, further comprising interfacing protocolized data into the 
plurality of dissimilar networks using different protocols, 

29. The method of claim 18, further comprising adapting data to be transported 
between the first device and the second device, the data being adapted between a first device 
format utilized by the fu-st device and at least one of a plurality of digital and analog network 
formats utilized by the plurality of networks. 

30. The method of claim 29, further comprising: 

determining network selection criteria; i 
dynamically selecting a network fi-om the plurality of networks in accordance with the ' 
selection criteria; 

switching to the selected network; 

dynamically selecting a next network from the plurality of networks in accordance 
with the selection criteria; 

determining whether to switch to the next selected network; 

switching to the next selected network in response to a result of the determination. 

3 1. The method of claim 30, fiirther comprising: 

transporting the data over the selected network in accordance with one of die network 
transmission formats; 

receiving the transported data from the network; 

adapting the transported data between one of the network formats and a second device 
format utilized by the second device; and 

forwarding the transported data to the first device in accordance with the first device 
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32. The method of claim 18, in which the pluraHty of parallel wireless networks 
comprise at least one of digital networks and analog networks. 

33. The method of claim 18, in which the plurality of parallel wireless networks 
comprise at least one wireless network and at least one wireline network, 

34. The method of claim 18. in which the data comprises digital data. 

35. The method of claim 34, in which the digital data fiirther comprises digital voice. 

36. A method of dynamically routing data between a first device and a second device 
over a plurality of parallel wireless networks, at least two of the networks being dissimilar, 
the method comprising: 

monitoring the status of the at least two dissimilar networks. 

37. The method of claim 36, further comprising routing the data througji at least one 
of the dissimilar networks. 

38. The method of claim 36, further comprising selecting a network to be used for 
data transport based upon the monitoring. 

39. The method of claim 38, in which the selecting occurs when the selected network i 
becomes unavailable. 

40. The method of claim 36, further comprising determining network selection 

criteria. 

41. The method of claim 40, further comprising selecting a network to be used for 
data transport based upon the monitoring and the network selection criteria. 

42. The method of claim 41, further comprising switching to the selected network. 

43. The method of claim 42, in which the switching networks occurs inmiediately 
after transporting a first data packet and before transporting a subsequent consecutive data 
packet. 

44. The method of claim 36, further comprising transporting data via a plurality of 
protocols comprising at least Internet Protocol (IP), and transparent protocol over the 
plurality of networks. 

45. The method of claim 36, further comprising transporting data between the first 
device and the second device in accordance with the routing, and detecting and correcting 
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errors in transmission of the transported data. 

46. The method of claim 36, fiirther comprising interfacing protocolized data into the 
plurality of dissimilar networks using different protocols. 

47. The method of claim 36, further comprising adapting data to be transported 
between the first device and the second device, the data being adapted between a first device 
format utilized by the first device and at least one of a plurality of digital and analog network 
formats utilized by the plurality of networks. 

48. The method of claim 47, further comprising: 
determining network.^selection criteria; 

dynamically selecting a network fi-om the plurality of networks in accordance with the 
selection criteria; 

switching to the selected network; 

dynamically selecting a next network from the plurality of networks in accordance 
with the selection criteria; 

determining whether to switch to the next selected network; 

switching to the next selected network in response to a result of the determination. 

49. The method of claim 48, further comprising: 

transporting the data over the selected network in accordance with one of the network 
transmission formats; 

receivingrthe transported data from the network; 

ad^ting the transported data between one of the network formats and a second device 
format utilized by the second device; and 

forwarding the transported data to the first device in accordance with the first device 
format. 

50. The method of claim 36, in which the plurality of parallel wireless networks 
comprise at least one of digital networks and analog networks. 

51. The method of claim 36, in which the plurality of parallel wireless networks 
comprise at least one wireless network and at least one wireline network. 

52. The method of claim 36, in which the data comprises digital data. 

53. The method of claim 52, in which the digital data further comprises digital voice. 
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54. A system for end-to-end data communications where data is transported between 
a local device and a remote device using at least one of a plurality of parallel wireless 
networks, at least two of the networks being dissimilar, the system comprising: 

a plurality of network interfaces, each network interface interfacing the local device 
with one of the neuvorks, the network interface comprising a local device 
protocol-appropriate communications controller connected to the local device; and 

a router that interfaces the plurality of parallel wireless networks to the remote device, 
the router comprising a monitoring system that is capable of monitoring the status of the 
plurality of dissimilar netwprks. 

55. The system of claim 54, in which at least two of the wireless networks 
simultaneously actively connect the network interfaces and the router. 

56. The system ol' claim 54, fiirther comprising a mobile data controller that 
communicates over at least one of the plurality of parallel wireless networks to the remote 
device, the mobile data controller comprising a remote device communication interface 
module that adapts data to be transported between the local device and the remote device, 
the remote device communication interface module adapting the transported data between^^ 
a remote device transmission format utilized by the remote device and one of a plurality of 
analog and digital wireless link transmission formats utilized by the plurality of parallel 
networks. 

57. The-system for transporting data according to claim 54, wherein the network 
interface is adapted to be connected to a plurality of different types of local devices havmg 
distinct transmission characteristics. 

58. The system for transporting data according to claim 54, in which the plurality of 
network interfaces are connected by a local network and a synchronization system that 
synchronizes the transfer of information between the plurality of network interfaces, the 
information comprising routing tables and health and status information. 

59. The system of claim 54, in which the status comprises at least one of installation 
status, network health, configuration status, and network availability. 

60. The system of claim 54, in which the router further comprises: 
a system for determining network selection criteria; 
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a selector for dynamically selecting at least one of the plurality of networks in 
accordance with the network selection criteria; and 

a switch for switching to the at least one selected network so that datia can be 
transported between the first device and the second device over the at least one selected 



61. The system of claim 60, in which the switch is capable of switching networks 
immediately after transporting a first data packet and before transporting a subsequent 
consecutive data packet. 



network fi-om the plurality of networks in accordance with the network selection criteria 
when the selected network becomes unavailable. 

63. The system of claim 62, in which the switch is capable of switching to the next 
^network when the selected network becomes unavailable. 

64. The system of claim 54, in which the plurality of wireless networks comprise at 
least one wireless network ;md at least one wireline network. 

65. The system of claim 54, in which the router fiirther comprises a system for ^ 

i 

interfacing protocolized data into the plurality of dissimilar networks using different* 
protocols. 

66. The system of claim 54, in which the plurality of networks comprise switched 
networks. ; 

67. The system of claim 54, in which the plurality of networks comprise dedicated 
networks. 

68. The system of claim 54, in which the plurality of networks comprise switched 
networks and dedicated networks. 



69. The system of claim 54, in which the plurality of networks comprise at least one 
of digital networks and analog networks. 

70. The system of claim 54, in which at least one of the plurality of networks 
comprises a packet based wireless network. 



71. The system of claim 54, in which the monitoring system determines whether the 
a network is available for data transport. 



network. 



62. The system of claim 60, in which the selector is capable of determining a next 
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72. The system of claim 56, wherein the mobile data controller is capable of being 
connected to a plurality of different types of remote devices having distinct operational 
characteristics. 

73. . The system of claim 54, wherein each network interface fiirther comprises a 
plurality of communication interfaces adapted to transfer the transported data to a plurality 
of networks. 

74. The system of claim 54, in which the data is transported via a plurality of 
protocols comprising at lesist Internet Protocol (IP), and transparent protocol over the 
plurality of networks. 

75. The system of claim 60, in which the selector further determines a next wireless 
communications link from the plurality of networks in accordance with the network selection 
criteria when the selected network becomes unavailable. 

76. The system of claim 60, in which the network selection criteria comprises 
network availability and the selector selects at least one of the plurality of dissimilar 
networks when a current netAVork becomes unavailable. 

77. The system of claim 54, in which the local device comprises a plurality of local ^ 
devices. 

78. The system of claim 54, in which the data comprises digital data. 

79. The system of claim 78, in which the digital data fiirther comprises digital voice. 
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